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

[Uoti Urpala]

On Tue, 2014-02-11 at 21:52 +0000, Colin Watson wrote:
> On Tue, Feb 11, 2014 at 10:18:52PM +0200, Uoti Urpala wrote:
> > I think this would benefit from a more clear explanation of the

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

The description itself looks OK, but I think a section title like
"per-connection sshd instances" (or "per-connection sshd instances under
systemd" if you want to emphasize the description only works under
systemd) would be preferable to the current "systemd socket activation".


> > 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)?

At least a script from another package could trigger a daemon-reload
call between unpacking openssh-server and configuring it. So the system
could at least be in a somewhat inconsistent state between that and the
start-stop-daemon call. However, when writing the above I was somehow
confused between start-stop-daemon and invoke-rc.d - raw
start-stop-daemon should work regardless of the confused state. The
problem preventing it from being stopped is likely a simple incorrect
negation in the postinst: the stop call is under "! systemctl --quiet
is-active ssh" - only stopping it if it's already NOT active.