On Mon, Feb 17, 2014 at 08:32:41PM +0200, Uoti Urpala wrote: > On Wed, 2014-02-12 at 00:13 +0000, Colin Watson wrote: > > On Tue, Feb 11, 2014 at 03:37:28PM -0800, Shawn Landden wrote: > > > After upgrading to sid I ended up getting only the socket-activated > > > sshd, and having ssh.service fail to the port being already taken by > > > ssh.socket. I had to > > > systemctl disable ssh.socket > > > > Yes, Michael spotted that earlier in this thread, and I fixed it in > > 1:6.5p1-2. > > There's still one problem in the .service / .socket interaction: the > socket should have a "Before=ssh.service" in addition to > "Conflicts=ssh.service". Bare "Conflicts" only guarantees that any > command scheduling start of one will also schedule a stop of the other. > An ordering dependency is needed to guarantee that the stop has finished > before the other is started (as is necessary in this case, as the > listening socket must be freed before the other can claim it). In the > "Conflicts" case it shouldn't matter whether it's "Before" or "After".
Thanks; I've fixed this in git for our next upload. > The "invoke-rc.d ssh restart" in postinst can also cause problems. If > you do "systemctl start ssh.socket" without permanently disabling the > service (as mentioned in README.Debian), then upgrading (or, easier to > test, running "dpkg-reconfigure openssh-server") will restart > ssh.service and stop ssh.socket. Using "try-restart" unless the service > was running and the script stopped it earlier would probably be better. This is rather awkward to change, since the invoke-rc.d call is in a debhelper autoscript. Furthermore, I'm not sure if it would be a correct change to make in general. Let us say that sshd is broken for some reason and we fix that in an upgrade; I think in that case it actively makes sense to start it even though it wasn't previously running. (There's also of course the question of whether the package should honour a change that the admin has not chosen to make permanent ...) A bit less invasively, we could check whether ssh.socket is running, and if so, explicitly restart that rather than ssh.service. This is still pretty awkward in terms of debhelper integration, though. I think I would rather just say that if you don't disable ssh.service permanently then it may be restarted on package upgrades. That is, a package upgrade should generally do its best to take you into the same state you'd reach if you were to reboot. -- Colin Watson [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
