[Pkg-systemd-maintainers] systemd support in openssh-server

[Colin Watson]

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                                       [cjwatson at debian.org]