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

[Uoti Urpala]

Colin Watson wrote:
> On Tue, Feb 11, 2014 at 12:32:34AM +0100, Michael Biebl wrote:
> > Do you think it would be helpful if we write a small paragraph in
> > README.Debian explaining the two different modes and how to enable/use them?
> 
> I already did. :-)
> 
>   systemd socket activation
>   -------------------------
>   
>   If you want to reconfigure systemd to launch sshd using socket activation,
>   then you can run:

I think this would benefit from a more clear explanation of the
activation mode, namely that it means launching a per-connection daemon
in "Accept=yes" mode. As written, this could be confused with default
systemd socket activation mode, as in systemd passing a listening socket
to sshd (which would be strictly superior to the current behavior with
sshd opening the socket itself, but which is not supported by upstream
sshd yet AFAIK). 


> > I also wonder why the following check was added:
> > 
> > ExecStartPre=/usr/bin/test -c /dev/null
> > 
> > Why is this needed? Seems rather odd to me. With devtmpfs being
> > mandatory (in systemd/udev) nowadays, /dev/null is guaranteed to exist.
> > Do you remember why this check was added? Afaics it doesn't seem
> > necessary anymore nowadays.
> 
> Russ already provided a link to the original bug.  While I never tracked
> down the exact script that was at fault for the users in question, as
> it's very difficult to find retroactively, it can happen any time some
> script accidentally does "rm /dev/null", at which point the next thing
> to run as root and redirect to /dev/null will create it as a regular
> file.  Nothing about systemd/udev prevents this from happening.  Yes,
> this is absolutely somebody else's bug, and it seems to be pretty rare,
> but when it happens I don't want to have to spend time dealing with the
> bug reports.  A quick test call seems worth it.

IMO it seems questionable to do this in the startup script of a single
package. If it's a common enough problem to matter then it should be
done more centrally, such as systemd itself doing a sanity check. And if
it's a meaningful sanity check for sshd in particular, then it looks
like something that should be added to the binary rather than be run as
a separate shell check.


There also seems to be a problem with transitioning from the init script
to the .service on a system with sshd running. I got messages like
"sshd[25017]: error: Bind to port 22 on 0.0.0.0 failed: Address already
in use." in journal, while the old sshd process from before the upgrade
was still running. I think the problem is that the .service is installed
and "systemctl daemon-reload" run while the old initscript-started sshd
is running, and this sshd was started WITHOUT "-D". This process is not
recognized as the main process, but is left to run under the .service,
which has "KillMode=process".

Postinst has a comment saying "We must stop the sysvinit-controlled sshd
before we can restart it under systemd." and a "start-stop-daemon
--stop" call, but I think this is too late - the above has already
happened and the --stop will no longer work.