Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

RFC: an(other) UNIX daemon module implementation

by mantager (Sexton)
on Jun 25, 2012 at 10:10 UTC ( #978175=perlquestion: print w/ replies, xml ) Need Help??
mantager has asked for the wisdom of the Perl Monks concerning the following question:

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.

Comment on RFC: an(other) UNIX daemon module implementation
Re: RFC: an(other) UNIX daemon module implementation
by Anonymous Monk on Jun 25, 2012 at 11:04 UTC
    there's many more daemon-related distributions on cpan than the 3 you listed. if none of the existing cpan distributions meet your criteria, first see if it's possible to patch one of the cpan dists before creating a new dist.

      I am still searching, actually, though I do not seem to find what I'm searching for. That's the first reason why I posted here, after all.

Re: RFC: an(other) UNIX daemon module implementation
by afoken (Parson) on Jun 25, 2012 at 17:50 UTC

    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
    Getopt::Long?
    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.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

      Handle natively command line parsing, allowing the developer to specify extra command line options she might expect, and provide easy access to such configuration

      Getopt::Long?

      Of course :)

      Thanks Alexander,
      this is interesting. I'll take a look at daemontools.

        daemontools come from primordial times when BSDs had just rc.local and SYSV bare init.d start stop scripts. I would recommend to reconsider your operating system's wheels. They are pretty round nowadays:
        • systemd for most Linuxes
        • upstart for Ubuntu
        • launchd for OSX
        • SMF for Solaris
        • even rc.d on *BSD and init.d elsewhere should be good enough for easy administration - notably the check/status, reload parameters
        I certainly would hate an application which came with its own service management scheme and which made me ferret out its own special way of telling me its status. Just because some purity rule says: no "mixing the daemon executable with its controlling script."

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://978175]
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (7)
As of 2014-08-22 05:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (147 votes), past polls