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

[Colin Watson]

On Tue, Feb 11, 2014 at 10:18:52PM +0200, Uoti Urpala wrote:
> Colin Watson wrote:
> > 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). 

OK.  I've pushed this commit:

  http://anonscm.debian.org/gitweb/?p=pkg-ssh/openssh.git;a=commitdiff;h=a92ab9ee301bc9196bb20f4923886f021f070521

Let me know if that still looks wonky.

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

I don't have a broad enough view of this to know whether it's common
enough to matter.  As a general rule when I add this kind of check I
won't remove it unless I've seen a conclusive demonstration that the
root cause has been fixed (which seems unlikely in this case since it
probably isn't a single root cause) or it's already been superseded
elsewhere.  So I don't mind if systemd wants to do it but until then
I'll keep the check in my service file.

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

Well, of course it is already done in the binary by way of libc's
daemon(), it's just that the error message is dreadful. :-)  It hasn't
been *that* important to me so I just went for the lowest-maintenance
approach rather than refining it; I've already spent more time
discussing it in this thread than I spent maintaining it in the last six
years.

Again, yeah, it probably ought to be done in the binary and upstreamed
etc., I've just had better things to do.  I don't mind if somebody feels
the need to chase this upstream.

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

Curious.  I thought I'd tested this upgrade path.  What would have
called daemon-reload?  Do you by chance happen to have a log of the
upgrade (say, from /var/log/apt/term.log)?

If the old initscript-started sshd is still running, I would have
expected its pid file to still be around, in which case
start-stop-daemon should work.  Perhaps I'm missing something.

-- 
Colin Watson                                       [cjwatson at debian.org]