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. 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. 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. I observe that upstart's UPSTART_FDS, if extended to multiple sockets, would require the daemon to do whitespace-separated parsing to extract the (perhaps noncontiguous) fds. Whereas systemd's two separate variables and use of a contiguous fd range is slightly easier to deal with. AFAICT it might be possible for both daemons to implement both protocols. upstart would have to arrange to make sure that if there were multiple fds they were consecutive. Observations and/or opinions from either upstart or systemd welcome. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
