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

[Shawn Landden]

On Tue, Feb 11, 2014 at 1:52 PM, Colin Watson <cjwatson at debian.org> wrote:
> 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.
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

>
>> > 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]
>
> _______________________________________________
> Pkg-systemd-maintainers mailing list
> Pkg-systemd-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers



-- 
Shawn Landden
+1 360 389 3001 (SMS preferred)