systemd (Was Re: tmpfs for strategic directories)

[Björn Persson]

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

To handle different command line syntaxes I would apply some simple macro 
substitution to the command line in the .service file, replacing for example 
the string "%listen_FDs%" (or some other syntax) with the number of sockets. 
One daemon could then have the parameter "--listen-fds=%listen_FDs%", another 
could have "-sockets=%listen_FDs%" and a third could have "-q %listen_FDs%".

> 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[].

I'd be surprised if any of those programs are designed such that they have no 
way of passing parameters to their modules.

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

I'm afraid I don't understand what you mean with "handle this". I thought at 
first that you meant that LISTEN_FDS should only be used for daemons that are 
known to clear it, but if that were the case you wouldn't have invented 
LISTEN_PID. Do you perchance mean that LISTEN_FDS should only be used in cases 
where all child processes will be killed if the daemon dies?

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100602/76011ac7/attachment.bin