in reply to RFC: an(other) UNIX daemon module implementation
Consider using daemontools. See also http://thedjbway.b0llix.net/daemontools.html.
- Have an OO interface (I find it easier to code, manage and document such interfaces...)
- You won't need an interface. A trivial daemontools daemon needs less than ten lines of shell code.
- Handle the "basic" daemonizing stuff, as stated in Re: perl daemon
- daemontools will take care of that
- Drop privileges
- daemontools will take care of that
- Log to syslog by default
- daemontools prefer logging to multilog, but of course, you can replace that with the logger command that will log to syslog.
- Optionally log to file instead of logging to syslog
- daemontools prefer logging to multilog, and multilog keeps a set of log files.
- Optionally leave the developer use her own logging system
- daemontools allows you to have your own logging, if you like, but it is much easier just to write all logging data to STDERR.
- Close STD* file handles, and then optionally tie them to the logging subsystem, so that the developer might choose to use the logger or simply print() something and get it logged anyway - this would ease migrations from "regular" scripts to daemons
- daemontools will take care of that, if you like. By default, STDIN reads /dev/null, STDOUT and STDERR go to the logger.
- Handle __DIE__ and __WARN__ so that messages can be logged and don't get lost
- daemontools will take care of that, automatically. Messages won't even get lost if your daemon crashes.
- Handle HUP signal as restart by default, leave the developer free to disable/redefine this behavior
- You can handle signals with daemontools as you like. The daemontools take care of restarting your daemon if needed.
- Be able to parse a config file and provide easy access to this configuration via a Config::General(::Extended) structure; or, maybe: expect a config file on default locations (/etc, /usr/local/etc, ...) unless configuration is directly provided when initializing the daemon object
- That's not strictly daemon related. The daemontools prefer that you pass your configuration via environment variables, but you don't have to use that mechanism.
- Handle natively command line parsing, allowing the developer to specify extra command line options she might expect, and provide easy access to such configuration
- Optionally provide an exclusive locking by opening and locking $0 (or the pidfile) so that running multiple instances can easily be avoided
- Daemontools take care of that. You don't need PID files, and you don't need locking.
- Have methods for configuration (re)loading and log (re)initialization so that the developer might choose to implement the handler of HUP signals just in terms of conf-reloading/log-reopeinig
- If you allow the daemontools to restart your daemon script, you don't have to care about that.
- Provide a -f flag for "foreground"
- Evil. You don't need that with daemontools. Your daemon always runs "in foreground", daemontools make you think it runs "in background".
- Provide a -d flag for "debug"
- Use the environment. Or the configuration file.
- Things I think one should avoid: Handling command line parameters such as "start", "stop", "status": when the daemon is launched it should start, when the process is killed with the TERM signal it should cleanup and exit.
- This is exactly the behavior that the daemontools expect.
- I think there should be no "status" method, because this means mixing the daemon executable with its controlling script. [...] If a daemon must provide some "status" function (e.g.: like the openvpn daemon, which writes status to system logs), the implementation is left to the developer (and can be triggered by a signal, for example).
- Deamontools handle command line arguments. To start, use svc -u mydaemon. To stop, use svc -d mydaemon. To get status information, use svstat mydaemon. Daemontools also can send signals to the daemon program, e.g. svc -h mydaemon sends SIGHUP, svc -a sends SIGALRM, and so on. There is a patch that adds SIGUSR1, SIGUSR2, and SIGQUIT.
- Forcing the developer to specify configuration for chroot, chdir, privilegs drop, pidfile, umask. If configuration is not given, the action must be skipped
- Deamontools handle that, too.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)