On Sat, Jun 01, 2013 at 03:53:15AM +0200, Lennart Poettering wrote: > [...] I remember even emailing the Upstart guys about > that, but I never got any reply. This was a long long time before Upstart > added socket activation.
This appears to be the discussion starting with this mail: https://lists.ubuntu.com/archives/upstart-devel/2011-March/001436.html I will now summarize that discussion and add some further remarks and questions. On Wed Mar 16 23:18:13 UTC 2011, Scott James Remnant wrote[1]: > It's perfectly acceptable, just Upstart doesn't define it because the > fds passing is more generic than just "listening sockets" like in > systemd. Likewise since Upstart actually supports daemon processes, > rather than telling them not to do that, LISTEN_PID isn't appropriate > either. > > But because it's a superset, jobs that call binaries which are > compatible with systemd instead of Upstart can just do: > > exec env LISTEN_FDS=$UPSTART_FDS LISTEN_PID=$$ ... Lennart later pointed[2] out that the interface upstart proposed is not a superset of the interface implemented in systemd (passing multiple sockets). Let me also briefly pick on Scott's quote. In the responses I failed to get what other kinds of fds can be shipped via UPSTART_FDS. Maybe this was about fifos? Maybe the specification of what can be passed via LISTEN_FDS can be broadened on the systemd side? When I look at existing daemons that bind sockets, the usual approach is to first open the sockets, then drop privileges and then fork. Reasons for this order: * fork as late as possible, to be able to report errors in early initialization and possibly to signal completion of startup. * bind sockets before dropping privileges. So arguably the LISTEN_PID variable isn't as problematic as Scott suggests. Are you aware of a service, that binds sockets after daemonizing (and has no method to inhibit the daemonizing all together)? I rather dislike the suggestion to fix the differentiation of interfaces inside upstart job files. This just clutters them and makes upstart appear inferior. Clint Byrum also acknowledged[3] the need for a common API and he really nailed it. On Mon Mar 21 18:38:08 UTC 2011, Clint Byrum wrote[3]: > I see this as a situation where we can share technology and establish a > standard that works well with both our solutions. The worst thing we can > do right now is disagree on how to ask daemon upstreams to patch their > daemons. If upstart does this one way that is entirely incompatible w/ > systemd, and they both get real traction, then we will just create a > giant inefficiency and gridlock where we have daemons who have gone "the > upstart way" and others who have gone "the systemd way", and neither > trusting that the other is worth doing. Observe that two years later, we have almost reached the point Clint envisioned as a worst case. Following the thread, one can observe that communication between Lennart and Scott is not ideal. This is just sad, and I am not to blame either of them. Maybe we can get both to a table now by mediating the discussion? To me the crux appears to be that upstart wants to support passing sockets to services, that deamonize and bind those sockets after daemonization. (In systemd speak that'd be Type=forking and in upstart speak that'd be "expect fork" or "expect daemon".) This is something not supported by the interface proposed by systemd. But is it really worth supporting? Helmut [1] https://lists.ubuntu.com/archives/upstart-devel/2011-March/001443.html [2] https://lists.ubuntu.com/archives/upstart-devel/2011-March/001444.html [3] https://lists.ubuntu.com/archives/upstart-devel/2011-March/001459.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130601090304.ga32...@alf.mars