systemd (Was Re: tmpfs for strategic directories)

Lennart Poettering mzerqung at
Tue Jun 1 00:52:03 UTC 2010

On Wed, 26.05.10 14:47, Simo Sorce (ssorce at wrote:

> > environment variables are normally inherited when forking/execing. We
> > want to make sure that only the process we actually start ourselves
> > parses and handles LISTEN_FDS. We want to avoid that if this daemon
> > might spawn some other process, it might get confused into handling
> > LISTEN_FDS, although that env var wasn't actually intended for it.
> > 
> > And hence we say that LISTEN_PID should be verified first, and only if
> > it matches LISTEN_FDS should be handled.
> If you are mandating behavior in daemons, wouldn't it be simpler to
> mandate the daemon unsets LISTEN_FDS ?

Yes, our reference implementation actually does that. But we didn't want
to rely on that, simply because handling the environ[] array is so messy,
since memory allocation is not clear and the whole thing is not
thread-safe. In many case environ[] should probably be considered a
read-only data structure during runtime.

> If I replace the process with a script, or the dameon runs other
> processes LISTEN_PID is going to be wrong anyway, not sure how useful
> it really is.

Nah, as long as the script calls exec() in the end it should be fine, as
the PID isn't changed on exec(). Note that for the purpose of
baby-sitting it is kinda nice to know which process is the main process
of a daemon, hence needless fork()ing on startup sucks anyway, and
should better not be done if we can.

> You are assuming that the process you run is always going to be *the*
> daemon. I think it is an unrealistic assumption to make.

Oh, its very much realistic I think. It holds for every single of the 10
daemons or so from the default F13 install and beyond I have patched so


Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net           GnuPG 0x1A015CC4

More information about the devel mailing list