systemd (Was Re: tmpfs for strategic directories)

[Nils Philippsen]

On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote:
> On Wed, 26.05.10 22:06, Björn Persson (bjorn at rombobjörn.se) wrote:
> 
> > This suggests to me that environment variables isn't the right way to do this. 
> > Environment variables are good for parameters that should be available to many 
> > processes. Command line parameters are better when the parameter is only meant 
> > for one specific process. I can see how looking up two environment variables 
> > may be a smaller patch than adding a parameter to the program's command line 
> > parser, but I still think it should be done with command line
> > parameters.
> 
> This is a valid point and we have pondered this for a while and in the
> end decided to use environ[] instead of argv[], simply because this
> allows us to use the same code for handling it in all daemons, while
> handling --listen-fds=xxx in argv would work for some daemons, but not
> for others. (i.e. some don't do long getopt, others do it with one dash
> only). Also, quite a few projects (rsyslog for example) implement socket
> handling in loadable modules, where we have no access to argv[] but do
> have access to environ[].

>From looking at /etc/rsyslog.conf, rsyslogd already seems to have a
means to pass configuration into its modules. Offering the same
interface on the command line shouldn't be rocket science.

> > LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the 
> > original daemon is restarted but its children live on, then later some 
> > descendant process may get the same PID as the original daemon, and may try to 
> > handle LISTEN_FDS. The risk may be low, but I always prefer a solution that is 
> > guaranteed to work over one that mostly works.
> 
> Well, this is purely theoretical, since LISTEN_FDS should normally only
> be set for daemons that can actually handle this and hence as long as
> these are running none of their children can get the same PID.

Daemons are known to occasionally go down unplanned and as I read it,
systemd is intended to restart them in that case. While child processes
could then be killed off via the cgroup to which they belong, this is
not always desirable, think of sshd and the children it forks for every
login.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011