Bug#727708: upstart and upgrading from sysvinit scripts
Steve Langasek <vorlon@debian.org> writes:
> 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. However, this is not borne out
> by my experiments with systemd on Fedora (which I would presume to be
> the go-to source for best practices of systemd service activation).
My understanding (not having looked at Fedora at all myself) is that
rsyslog would be a better choice of package to look at. It sounds like
both of the packages you chose are inappropriate examples; for ssh, Fedora
made an intentional choice to use inet-style activation, and for rsync, it
sounds like the conversion is incomplete or untested.
> 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.
I don't see any reason why this would be the case, although it does point
out that I got my original implementation wrong in the ways that Uoti
pointed out, and some additional documentation would be helpful.
If the service is configured to use socket activation, it should depend on
the corresponding socket unit (and in general, unless there is other
necessary initialization beyond binding a socket, use Type=simple), at
which point I don't see any reason why there would be boot-time races.
Even if it doesn't, my understanding is that the socket target is started
before any of the services in multi-user.target, so there still shouldn't
be a problem. (But the explicit dependency seems like better form.)
> 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!
Did the cups service unit explicitly depend on its socket unit?
> Of course, it's entirely possible that I've misunderstood something
> here, so I welcome your investigations with lbcd. I'm very interested
> to see if your understanding of systemd socket-based activation best
> practices matches my own, and to have an opportunity to experiment with
> socket-based activation in the more relevant environment of Debian
> unstable rather than Fedora.
Uoti's reply to your message matches my experience. I just rebooted the
system on which I've been experimenting (after fixing the typo in the
current unit file!), and here is the output from systemctl status lbcd
immediately after boot:
lbcd.service - responder for load balancing
Loaded: loaded (/lib/systemd/system/lbcd.service; enabled)
Active: active (running) since Sun 2013-12-29 10:20:19 PST; 57s ago
Docs: man:lbcd(8)
http://www.eyrie.org/~eagle/software/lbcd/
Main PID: 886 (lbcd)
CGroup: name=systemd:/system/lbcd.service
└─886 /usr/sbin/lbcd -f -l
Dec 29 10:20:19 wanderer systemd[1]: Started responder for load balancing.
Dec 29 10:20:19 wanderer lbcd[886]: ready to accept requests
As you can see, lbcd was started immediately on boot and passed its
socket. I also confirmed with netstat that the socket was bound by
systemd, not by the lbcd daemon. So this all seems to be working the way
I would expect, and is not lazy.
One could of course make it lazy by not starting lbcd in the multi-user
target, and I could see some circumstances where that would be useful, but
that's not the default behavior.
This does indeed not work correctly with the version of lbcd in the
archive, but that's just due to my errors, specifically the typo in the
WantedBy configuration. I'll be making another upload later today fixing
the issues that Uoti identified. (This is the sort of thing that we would
want to document in Policy.)
I don't see any signs that the problems you're worried about are present.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: