Re: RFC: an(other) UNIX daemon module implementation

[afoken]

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

[mantager]

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.

[pklausner]

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."

[aaron_baugher]

daemontools come from primordial times when BSDs had just rc.local and SYSV bare init.d start stop scripts.

Also known as The Good Old Days. :-) I get a little annoyed with the way I keep running into new ways to start/stop/status processes on Linux systems. They used to be in rcX.d, then init.d, and now when I run one of those, it tells me to use something called service. Seems like I've seen a couple other methods over the years. No, I'm not going to seriously argue that throwing everything into rc.local was better, but....

On daemontools: it does a lot more than init.d scripts. It supervises processes and restarts them if stopped, provides easy logging and automated rollover of logs, and more. Combined with ucspi-tcp utilities like tcpserver, you can take a Perl script that simply reads from STDIN and writes to STDOUT, run it from daemontools with a few lines of shell script, and turn it into a network daemon with user- and IP-based security, multiple connections, logging of errors, and restart on die. I don't know how many of those other services provide that, but it's pretty handy.

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.

Agreed. Apache always annoyed me that way, by having its own apachectl. Most distributions now wrap that in an rc/init script so you don't have to know about it, but it made it more of a hassle to supervise with a system of your own choosing.

[mantager]

Mmmm I didn't dig very deeply into daemontools, but it didn't seem somethig that mixed the daemon with the controlling script, although I may be mistaken (I just took a glance at it).
Rather, it seems to be a framework to provide systemd-like capabilities to the system.

systemd is likely to obsolete the concept of "daemon", since it takes care of all the work of launching an application in background.
- I like it - I was glad when Fedora adopted it :)
Unfortunately, I'm stuck on RHEL and CentOS 5/6 (you may read: support for Perl 5.8.8 required @_@)

As an exercise, I almost completely wrote the module I was thinking about - I'm implementing the "tie the handles to logging" part, now. It's quite funny :)

Cheers.