I'm looking for your wisdom on this topic: should I try to reimplement the wheel and write another daemon(izing) module?
I tried App::Daemon and Proc::Daemon, and looked at the pod of Net::Daemon, but none of those seem to fit exactly what I need. Or, rather, none of those seem to behave the way I would like.
I understand this might be a matter of personal inclination; what I'm really hoping is that someone might come up with a "there it is already" answer to this question.
From my point of view, here is what a daemonizing module should do:
- Have an OO interface (I find it easier to code, manage and document such interfaces...)
- Handle the "basic" daemonizing stuff, as stated in Re: perl daemon
- Drop privileges
- Log to syslog by default
- Optionally log to file instead of logging to syslog
- Optionally leave the developer use her own logging system
- 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
- Handle __DIE__ and __WARN__ so that messages can be logged and don't get lost
- Handle HUP signal as restart by default, leave the developer free to disable/redefine this behavior
- 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
- 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
- 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
- Provide a -f flag for "foreground"
- Provide a -d flag for "debug"
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. I think there should be no "status" method, because this means mixing the daemon executable with its controlling script. For clarity: the former is located under $whatever/bin, the latter is located under /etc/rc.d/init.d (usually). They are distinct entities (IMHO).
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).
- Forcing the developer to specify configuration for chroot, chdir, privilegs drop, pidfile, umask. If configuration is not given, the action must be skipped
These are the characteristics I would like to find in a daemonizing module, because this is what I feel I need when I start writing a daemon, but YMMV, so I'm looking forward for comments to refine this "draft" and see if I can come up with such a module (if there isn't already a module handling all this stuff).
Is someone sharing this view?