Bug#727708: upstart and upgrading from sysvinit scripts
On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote:
> However, I think this gets to the heart of why upstart upstream has avoided
> ever recommending the use of socket-based activation. There are some fairly
> fundamental problems that basically halted development of socket-based
> activation in upstart (beyond merging of Scott's original implementation,
> which is rudimentary, as has been noted), and a look at systemd usage on
> Fedora led me to believe that systemd had not overcome these problems at
> all.
As far as I can see, what you're saying here is 100% based on
misconceptions only, and has no connection to any real issues
whatsoever.
> If I'm not mistaken (no references to hand - sorry), systemd upstream has
> claimed in the course of discussions on debian-devel that lazy activation is
> not the purpose of socket-based activation, and that using socket-based
> activation does not require you to pay the service startup penalty at the
> time of first connection.
Yes, this is true. If you have a daemon configured to always start, and
then add a .socket unit for socket activation, this does not in any way
STOP the daemon from starting!
Any mechanism that directly starts a .service will continue to do so
regardless of the existence of a .socket. What a .socket adds is that
you can have the socket active while the service is inactive, and in
this state an incoming connection to the active socket will trigger
start of the service. Other services which make requests through the
socket can depend on the .socket only (as opposed to directly depending
on the .service) to allow this state.
> On Fedora 20, after enabling the sshd and rsync service+socket units (both
> installed but disabled by default on Fedora per their policies on running
> services out-of-the-box) and rebooting, I find that both port 22 and port
> 873 are bound by pid 1. Only upon connecting to the socket does systemd
> actually spawn the server (in the case of sshd, it spawns it as 'sshd
> -i', so has to start up the server anew on each connection; in the case of
> rsyncd, the .service definition is completely incompatible with socket-based
> activation and any attempt to connect results in the rsyncd.socket unit
> landing in a 'failed' state).
Assuming this is an accurate description, it sounds like an intentional
decision for ssh and a bug in rsyncd (as Josselin already said).
> If what one is trying to accomplish here is to provide a replacement for
> inetd, then this is perfectly sufficient. But if one is trying to use
> socket-based activation for the claimed purpose of ensuring service startup
> ordering without the need to declare explicit dependencies, then you must
> accept the penalty of lazy activation - which is almost never acceptable in
> a server context (where the purpose of the machine is to run the services
> that you have configured, and they should therefore not be started lazily),
> and suboptimal even in a client context (since not starting services that
> are on the critical path for boot until the client requests them will
> potentially lead to a significant boot-time slowdown, if all the services
> are doing this).
As above, your belief that systemd would force lazy activation has no
basis in reality that I can see.
> As far as I've been able to tell, the only solutions that would allow
> non-lazy socket-based-activation of services in systemd all introduce
> significant boot-time races, whereby it is no longer assured that systemd
> will bind to the socket (and passing the socket information via the
> environemnt) before starting the service. Indeed, when I looked at this
> problem on an earlier version of Fedora, I found what I believe to be a
> latent security problem in the cups units, because it was nondeterministic
> whether the service would start with sockets passed from systemd, or a
> different set of sockets as defined in the cups config!
>
> When I mentioned this to Lennart at DebConf this year, his response was that
> "cups was special". Well, after further investigation, I don't think it's
> true that cups is special. I think systemd socket-based activation is snake
> oil, that does not do what was promised without introducing hidden
> trade-offs which no one has been forced to acknowledge because too few
> developers are making use of this feature today to expose the integration
> problems.
If foo.service has "Requires=foo.socket", then on general principles it
would sound like a very obvious bug if the service ever starts without
foo.socket active. I'd like to hear of some evidence of such a bug
before taking it seriously. And even if such a bug somehow existed,
fixing it should be a straightforward bugfix.
Reply to: