Bug#715194: openssh-server: ship systemd unit files

[Colin Watson <cjwatson@debian.org>]

On Mon, Jul 08, 2013 at 10:26:03PM +0200, Sven Joachim wrote:
> On 2013-07-08 19:29 +0200, Colin Watson wrote:
> > On Mon, Jul 08, 2013 at 06:29:42PM +0200, Sven Joachim wrote:
> >> Attached is a patch that adapts the Fedora unit files[2] to Debian
> >> customs,
> >
> > Thanks, I'll look into these for my next upload.

Er, yeah.  Oops.  Really looking into it now!

The only other significant error I see in your patch is that we really
should not be going back to creating /var/run/sshd in the postinst; that
doesn't necessarily persist across boots and doing anything with it in
maintainer scripts is inappropriate.  But that's easy to rip out again,
since you also added tmpfiles.d support.

We also need to take special care to stop the sysvinit-controlled sshd
on upgrade if systemd is running, just as we do with Upstart.  I'll sort
this out.

> >> e.g. the units test for /etc/ssh/sshd_not_to_be_run and even check
> >> /dev/null (is that really necessary?).
> >
> > Yes.  Although sshd_not_to_be_run is deprecated, bear in mind that
> > people may be upgrading from old systems and expect their configuration
> > still to work.  I see no reason why a change of init system should
> > affect that. :-)
> 
> Actually I did not mean to take out this test, but only…
> 
> >  As for /dev/null, well, I never managed to track down
> > what was zapping it (#369964 et al) but I would rather keep a small
> > amount of cruft around to check for that than have to deal with confused
> > people filing bug reports.
> 
> …the /dev/null check.  While the init script can print an eligible error
> message, the systemd unit files and the upstart script will fail rather
> silently anyway.

While this is true, I think it's easier to follow this chain of logic:

  systemd unit fails to start
  -> look at systemd unit, see ExecStartPre lines
  -> run them and see what fails

than this one:

  log message says "daemon() failed: Success"
  -> ?

In fact, "systemctl status ssh" would say exactly which ExecStartPre
line failed, making it quite straightforward to debug in that case:

  $ sudo systemctl restart ssh
  Job for ssh.service failed. See 'systemctl status ssh.service' and 'journalctl -xn' for details.
  $ systemctl status ssh
  ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
     Active: failed (Result: start-limit) since Mon 2014-02-10 14:42:14 GMT; 16s ago
    Process: 1042 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
    Process: 1035 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=0/SUCCESS)
    Process: 1155 ExecStartPre=/usr/bin/test -c /dev/null (code=exited, status=1/FAILURE)

> Actually, shouldn't the test return 1 rather than 0 in the upstart
> pre-start script?

I think that was to stop it respawning.  (I should arguably have used
"normal exit 0 1" or similar.)

Anyhow, this is all committed now, and I'm finalising 1:6.5p1-1.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]