aperezdc / dmon Goto Github PK

The following printf statement will cause logging to fail:

printf("\nHello, World\n");

This is because freadline does not distinguish between EOF and an empty line.

It would be much better if dmon had a test suite. We need one.

Currently using --config/ -C only supports reading --long-options from a a file, and the commands (both the program and for logging) have to be specified in the command line. Compare to setting $DMON_OPTIONS: it can be used to supply any command line option, including the commands.

Ideally it should be possible to write a configuration file which is executable, and uses dmon as the interpreter:

#! /usr/bin/dmon --config

pid-file /run/example.pid
...

One wonderful option would detecting a different name in argv[0] and enabling a command line processing mode which emulates the bhavior of an init.d script:

% cat /etc/service.d/example
#! /usr/bin/env dservice

pid-file /run/example.pid
...

% /etc/service.d/example status
stopped
% /etc/service.d/example start  # Starts the service, no output.
% /etc/service.d/
% if /etc/service.d/example status running ; then echo 'Yo!' ; fi
Yo!
% _

You get the idea.

This is more of a discussion issue for now, and a braindump of some ideas that came to mind after noticing about #1. Once reading a whole configuration from the command line is supported, there a few more things that can be done without much effort — note how things build on each other in small incremental steps:

• Allowing using dmon --config as a shebang. Maybe even with a different name like dservice by checking argv[0]. Then service descriptions can be contained in a file instead of having to specify every option in the command line.
• Providing a named Unix socket for controlling the instance.
• Accepting sysvinit-style script arguments. For example, for a “script” with the dservice shebang at /etc/dservice/ntpd, the following should be possible:
  • /etc/dservice/ntpd status
  • /etc/dservice/ntpd start
  • /etc/dservice/ntpd stop
  • In general, dservice <servicefile | servicename> <command> [args...] will be equivalent to <servicefile> <command> <args...>.
• Support deriving certain settings from the name of the configuration file, for example if a file is called /etc/dservice/ntpd:
  • PID file: /run/dservice/ntpd.pid
  • Control socket: /run/dservice/ntpd.socket
  • Destination of log files:
    • In dlog single-file mode: /var/log/ntpd.log
    • In drlog rotated-dir mode: /var/log/ntpd/*
    • In dslog syslog mode: service ntpd in daemon log
  • Others?
• Service dependencies: A possible command over the control socket would wait-start: a process writes the command to the socket, and then waits for a message, which is sent once the process is known to have started or failed.
  • Multiple dependencies? Just open and do wait-start on their control sockets: the operation is idempotent, so for already-started services a response is generated immediately.
  • How would stopping services with dependencies work? For example, having a service ntpd depending on networkmanager raises the following doubts:
    • Does stopping ntpd also stop networkmanager if no other service needs it?
      • Some services may continue to run even if they are not required anymore by other services. In the example networkmanager should continue working so the users of the computer can continue accessing the network.
      • Maybe it makes sense to have “explicitly enabled” services (is “explicitly stopped” services better naming?).
    • Does stopping networkmanager also stop ntpd because the latter cannot work without a network connection.
      • Some services may continue working even after some of their dependencies stopped. Maybe specifying those dependencies does not make sense, or the way to go os differentiating between “soft dependencies” and “hard dependencies”.
• Emulate sd_notify() to a certain degree.

This might be by design but wanted to bring this up. After #10 is fixed, empty lines will still not be logged. This is due to logic in dlog, dslog, and drlog to skip empty lines.

From my perspective, if someone wanted to log an empty line, I'd vote to have that empty line show up in the log but would love your perspective on this.

Could you add a flag --interval-on-error which pauses xx seconds before restarting the app (if it dies with a non-zero exit code).

Right now, it just keeps immediately restarting the app on error which can hammer the system.

It would be great to take advantage of the fact that GitHub renders Markdown files to add some documentation to the repository. In turn, the Markdown files could be themselves used to assemble a mini-site using e.g. pandoc.

It would be nice to cover the following:

• Philosophy.
• Community / how to contact the author(s).
• Examples:
  • How to convert any normal program into a daemon using dmon (hint: it's trivial!).
  • How to use with tcpserver, ipsvd, or other socket server in the style of ucspi-tcp.
  • Using libnofork.so to prevent pesky daemons from forkin.
• Integrating with other systems:
  • sysvinit: How to use dmon in an init script.
  • systemd: How to use dmon in an unit.

NOTE: This is a tracking meta-issue. Please open a separate PR for each of the items above or, if discussion is relevant create a new issue and write down its number next to the items above.