Dear monks,
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:

  1. Have an OO interface (I find it easier to code, manage and document such interfaces...)
  2. Handle the "basic" daemonizing stuff, as stated in Re: perl daemon
  3. Drop privileges
  4. Log to syslog by default
  5. Optionally log to file instead of logging to syslog
  6. Optionally leave the developer use her own logging system
  7. 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
  8. Handle __DIE__ and __WARN__ so that messages can be logged and don't get lost
  9. Handle HUP signal as restart by default, leave the developer free to disable/redefine this behavior
  10. 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
  11. Handle natively command line parsing, allowing the developer to specify extra command line options she might expect, and provide easy access to such configuration
  12. Optionally provide an exclusive locking by opening and locking $0 (or the pidfile) so that running multiple instances can easily be avoided
  13. 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
  14. Provide a -f flag for "foreground"
  15. Provide a -d flag for "debug"

Things I think one should avoid:

  1. 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).
  2. 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?

Thanks,
cheers.

In reply to RFC: an(other) UNIX daemon module implementation by mantager

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.