On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote: > It's quite possible that I am doing something wrong, but I don't think this > is it. Each of the .service units in question already had > 'WantedBy=multi-user.target', and each of the .socket units had > 'WantedBy=sockets.target'; on Fedora these were all disabled by default (to > avoid any open ports by default), but upon enabling both the service and > socket units, I get the behavior described. > > I was seeing the same behavior with the lbcd package in Debian, but it turns > out this is due to the 'mutli-user' typo in lbcd.service. Once I've fixed > this (and created the proper 'enabled' symlink), I do see the lbcd process > being started at boot. So that much does seem to work as described, on > Debian. I'm not sure what to make of the Fedora setup, then, because other > services that are linked into /etc/systemd/system/multi-user.target.wants do > start up at boot, but neither sshd nor rsyncd is started when the .socket is > enabled.
Enabling .socket is only supposed to start the socket, and the daemon only if a connection arrives. If you want the daemon to start unconditionally, you should enable the .service, not just the .socket. > In that case, my concern is a different one - how can anyone claim > that systemd's socket activation is ready for prime time if even a service > as important as sshd hasn't been debugged in Fedora, one of the flagship > adopters of systemd? What makes you think it is buggy? So far I have seen no clear indication of any bugs, only use of per-connection daemon instances which you didn't like. And even if there were bugs, it is fairly easy to imagine how an ssh maintainer could break it in one release independent of any systemd issues. > (BTW, there's also both an sshd.service and an > sshd@.service here, adding to the confusion. I've attached all of the sshd > units in case you want to look at them.) Those look like there are alternative units for a persistent daemon and a per-connection daemon used with an "Accept=true" socket. The sshd.service one is persistent and does not use socket activation. The sshd@.service is a per-connection one instantiated for each connection to sshd.socket. You're probably supposed to enable either sshd.socket (for per-connection daemons) or sshd.service (for a persistent daemon). > This still leaves the concern I have about start-time races. According to > systemd.unit(5), using 'Requires=', as Uoti suggested to Russ, does *not* > guarantee ordering: but as I said at the end of https://lists.debian.org/debian-ctte/2013/12/msg00206.html there's an automatic "Before:" dependency created from sockets to identically named services. So it shouldn't be necessary to give it explicitly. > In my earlier investigations (which were on Fedora 17, IIRC), I definitely > found races where a service configured with a corresponding .socket would > *sometimes* start at boot time before the socket is bound, causing it to > fall back to its own config file and binding to its own sockets... which I'm not sure if some parts of the behavior have differed before. At least the code setting the default dependencies has not stayed exactly the same; I didn't try to find out whether the behavior has actually changed. Even with current systemd you could probably produce such behavior with suitable configuration - at least if you do NOT add a "Requires=" and create an "early boot" service that can run before sockets.target. > diligently keeping the two implementations in sync. Since > LISTEN_FDS/LISTEN_PID is the defined API for systemd passing the socket > information to the service, for systemd to ever fail to pass this socket > information, resulting in the service deciding that it's not *actually* > running under systemd and should fall back to a different mode, is > potentially a very serious problem. If you want to make sure your service never tries to start without socket activation, it should have Requires=foo.socket; none of the default relations are strong enough to strictly prohibit starting without a socket. I think at least the case where creating the socket fails and admin manually says "systemctl start foo.service" would always start the service without a socket otherwise. -- 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/1388347941.3938.293.camel@glyph.nonexistent.invalid
