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

[Uoti Urpala]

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".

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.

If the service is disabled, then the above does not occur, because
invoke-rc.d checks whether the init script is enabled, and if not,
silently ignores start/restart actions. However, this means that if ssh
is disabled but you run "systemctl start ssh", then upgrading the
package fails to restart the daemon. invoke-rc.d should probably always
do at least "systemctl try-restart" regardless of status (and in the
long run it of course should not depend on the presence/status of init
scripts for any functionality).