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 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/msg7.html -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x61u1fcadl@midna.zekjur.net
Bug#727708: systemd socket activation protocol rationale
On Sat, 2013-12-14 at 21:45 +, 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. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387060605.3938.6.camel@glyph.nonexistent.invalid
Bug#727708: systemd and upstart (mostly docs) bugs submitted
I've been RTFMing upstart and systemd. This has generated a number of bug reports. In case these are at of any interest here's a list. If anything particularly interesting happens in them, I'll mention it. #732127 [n| ] Does setuid also set the group(s) ? It should. #732122 [m| ] semantics of boolean event specification not defined in init(5) #732123 [m| ] usage of "stanza" not compatible with ordinary English #732125 [m| ] upstart-events(7) title is misleading #732126 [m| ] state machine semantics of "initctl restart" are unclear #732128 [m| ] Manpages missing cross-references to socket stuff #732130 [m| ] Please document event/job/process environment variables properly #732131 [m| ] Please document apparmor directives #732156 [m| ] Precise documentation for ExecStart command syntax #732157 [w| ] Want SIGSTOP-style daemon/service readiness notification I haven't yet finished with systemd's docs but I'm going to be doing something else today soon so I'll send this mail now. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21164.54454.290576.540...@chiark.greenend.org.uk
Bug#727708: systemd and upstart (mostly docs) bugs submitted
Ian Jackson writes ("systemd and upstart (mostly docs) bugs submitted"):
> I've been RTFMing upstart and systemd. This has generated a number of
> bug reports. In case these are at of any interest here's a list. If
> anything particularly interesting happens in them, I'll mention it.
I missed two:
> #732127 [n|] Does setuid also set the group(s) ? It should.
> #732122 [m|] semantics of boolean event specification not defined in init(5)
> #732123 [m|] usage of "stanza" not compatible with ordinary English
> #732125 [m|] upstart-events(7) title is misleading
> #732126 [m|] state machine semantics of "initctl restart" are unclear
> #732128 [m|] Manpages missing cross-references to socket stuff
> #732130 [m|] Please document event/job/process environment variables properly
> #732131 [m|] Please document apparmor directives
#732124 [w|] "initctl reload" behaviour should be configurable in job file
#732132 [w|] Want support for multiple-socket activation
> #732156 [m|] Precise documentation for ExecStart command syntax
> #732157 [w|] Want SIGSTOP-style daemon/service readiness notification
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21164.54576.150864.368...@chiark.greenend.org.uk
Bug#727708: systemd socket activation protocol rationale
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-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21164.53644.558573.119...@chiark.greenend.org.uk
Bug#727708: upstart proposed policy in Debian
Ian Jackson writes ("upstart proposed policy in Debian"):
> Having read the docs there I have some apparently unanswered questions
> about how the upstart proponents think we would use upstart in Debian.
I found policy 9.11.1 which I had unaccountably failed to notice
before. It answer the question of how to do the transition from
sysvinit to upstart, with a hideous shell rune. Perhaps the upstart
package could provide a cooked command and then we could all say
if init-is-upstart 2>/dev/null; then exit 1; fi
or something. (IIRC some comments earlier in this thread about some
corner cases during upgrades; perhaps my suggestionn would help there
too.)
It didn't answer my other questions.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21164.49001.314624.848...@chiark.greenend.org.uk
Bug#727708: upstart proposed policy in Debian
Having read the docs there I have some apparently unanswered questions about how the upstart proponents think we would use upstart in Debian. How will we cope with removed-but-not-purged services ? Do we advise people in favour of socket activation ? Do we deprecate "expect fork" and "expect daemon" ? (I would favour this - the approach there is pretty horrible.) Perhaps there is some ubuntu docs on this. I confess I didn't try very hard to find it, hoping we might have a suitable Ubuntu upstart expert on hand :-). Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21164.24315.114596.474...@chiark.greenend.org.uk
Bug#727708: upstart user jobs
I have some questions about these. Forgive me if I could just have looked up the answers: Are they enabled by default in jessie/sid ? (If the answer is "no" then feel free not to answer the rest...) In the manpage I read: | Note that a user job configuration file cannot have the same name | as a system job configuration file. I don't understand this restriction. It's sounds like it's referring to the pathnames in which case it's trivially true, so I assume it's referring to job names. In which case surely this is a troublesome restriction: what, for example, if a user, knowing that the sysadmin is going to install something that creates job "foo", creates a job "foo" themselves first ? Can two different users create two jobs with the same name ? The underlying purpose of the restriction would seem to probably be to make job names unqualified by username but unique across users, but that seems wrong to me. Does anything that user jobs do depend on upstart being pid 1, or being root ? Does the thing which reads (and watches) the user's configuration files run as root, or as the user ? I.e., what is the privilege separation ? The docs say: | Files in this directory will be read and an inotify(7) watch | created the first time a user runs initctl(8). Does this really mean that if I'm fiddling around with writing some jobs, but not quite ready yet, and say "initctl --help", my jobs will start to run ? Also, it would appear to imply that user jobs aren't started automatically at boot. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21164.20413.374688.190...@chiark.greenend.org.uk
