Bug#727708: systemd socket activation protocol rationale
Hi Ian,
[still sending this after Uoti’s reply, because my version has some more
detail]
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Why do only some of the environment variables start "SD_" ?
> We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.
SD_LISTEN_FDS_START is a #define from sd-daemon.h, not an environment
variable.
> 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
“In addition we set $LISTEN_PID to the PID of the daemon that shall
receive the fds, because environment variables are normally inherited
by sub-processes and hence could confuse processes further down the
chain” ¹
> it hard to wrap up a socket-activated daemon in a shell script.
I am not entirely sure what use cases you have in mind, but typically a
wrapper script at some point just execs the daemon itself, right? In
that case, it’s not a problem.
> I think it would be good, regardless of what the TC decides on the
> init system question for Debian, for systemd and upstart to converge
> on a single reasonable protocol.
Helmut Grohne has done some work in that direction², speaking to the
relevant people at DebConf 13 in person. I am not entirely sure about
the current status of these efforts, maybe Helmut can comment…?
① http://0pointer.de/blog/projects/systemd.html, feature 8
② https://lists.debian.org/debian-devel/2013/06/msg00007.html
--
Best regards,
Michael
Reply to: