[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: systemd socket activation protocol rationale



On Sat, 2013-12-14 at 21:45 +0000, Ian Jackson wrote:
> I've just been reading sd_listen_fds(3).  It's vaguely similar to
> upstart's socket activation protocol.  It supports multiple sockets
> (which is obviously important).
> 
> But I have a few questions about the details:
> 
> Why do only some of the environment variables start "SD_" ?
> We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.

You misread it: there is no environment variable SD_LISTEN_FDS_START.
The API defines the start value as the constant 3. There is a
corresponding #define in sd-daemon.h, but it is not communicated at
runtime.


> What is the rationale behind the use of the LISTEN_PID variable and
> the pid check ?  It seems to me that at the very least this might make
> it hard to wrap up a socket-activated daemon in a shell script.

To ensure that the environment values are never accidentally inherited
by any child process.


Reply to: