On 2/27/2011 1:10 PM, Reindl Harald wrote:
Thank you for your informations and very good documentation!
Has anybody an eye to systemd/postfix because systemd will
replace sysvinit/upstart in the upcoming Fedora 16 and
so also in future RHEL-Versions and maybe replace
upstart/sysvinit sooner or later in other distributions
because the design of systemd seems to be really good
Am 27.02.2011 19:01, schrieb Wietse Venema:
systemd seems much more well thought out and has a genuine service model
that captures (among other things) dependencies, resource quotas,
parallelization, lazy evaluation, and event registration. apparently, it
has a great deal in common with the similarly well-designed Apple
launchd, despite the fact than earlier poster showed that Apple violated
the startup API of postfix. anyway, i reproduce here for consideration,
though, the recommended daemon guidelines. not being familiar with
postfix startup code but only reading the recent posts, it seems systemd
compatibility would pose similar (and more?) problems that are posed
with upstart. also, it quite clearly states it is *very* Linux specific
which leaves a source tree creaking and clunking towards multiple
diverse targets with contortions well beyond an #ifdef pair. well, i
just put this out here to share my research.
http://0pointer.de/blog/projects/systemd.html
Writing Daemons
An ideal daemon for use with systemd does a few things differently then
things were traditionally done. Later on, we will publish a longer guide
explaining and suggesting how to write a daemon for use with this
systemd. Basically, things get simpler for daemon developers:
* We ask daemon writers not to fork or even double fork in their
processes, but run their event loop from the initial process
systemd starts for you. Also, don't call setsid().
* Don't drop user privileges in the daemon itself, leave this to
systemd and configure it in systemd service configuration files.
(There are exceptions here. For example, for some daemons there
are good reasons to drop privileges inside the daemon code, after
an initialization phase that requires elevated privileges.)
* Don't write PID files
* Grab a name on the bus
* You may rely on systemd for logging, you are welcome to log
whatever you need to log to stderr.
* Let systemd create and watch sockets for you, so that socket
activation works. Hence, interpret $LISTEN_FDS and $LISTEN_PID as
described above.
* Use SIGTERM for requesting shut downs from your daemon.
