socket activation interface

[Helmut Grohne]

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