Bug#751636: openssh-server: ssh sessions are not cleanly termined on shutdown/restart with systemd
On Sat, Dec 13, 2014 at 07:14:53PM +0100, Christoph Anton Mitterer wrote:
> On Sat, 2014-12-13 at 15:06 +0100, Marc Haber wrote:
> > /lib/systemd/system/ssh.service in current sid has
> > "After=network.target" in its Unit stanza and still not cleanly kills
> > off ssh sessions.
> Since the ssh.service unit file only starts the listener daemons and not
> the sessions neither explicitly stops the session processes... this is
> absolutely expected behaviour.
It might be expected by somebody very familiar with how new init
works. It is surprising to people who aren't and undresired by some of
them.
> On Sat, 2014-12-13 at 15:10 +0100, Marc Haber wrote:
> > That would be the systemd way to do it
> No, it would be the way to improve things when the were done wrong in
> the past,
"Wrong" is subjective. It might also be something people are used to
for decades.
> > and instantly spawn a new hate
> > wave. After all, it was systemd locking people out of their headless,
> > remote systems during an urgent security update.
> Since such behavioural change wouldn't depend on the initsystem, just
> stubborn people who annoy us with their systemd FUD and hatred anyway
> would do so...
Unfortunately, there are many of those people.
Btw, with systemd sticking its head in many parts of the system that
are traditionally not an init's job, it is hard to judge whether a
change is introduced by systemd or not. People are going to take the
easiest route to vent.
> On Sat, 2014-12-13 at 15:16 +0100, Marc Haber wrote:
> > Do I understand correctly, that ssh in jessie/sid allows the local
> > admin to run sshd as a traditional daemon, with the new (undesired)
> > behavior, or as a systemd service with socket activation, which
> > gives a better emulation of traditional behavior?
> No, you don't understand correctly.
> In daemon mode, the "new" behaviour is a bug, reported in this very
> ticket.
As long as we agree on this being a bug, we are fine with each other.
> In socket mode, each session is controlled by what compares to the
> listener daemon (i.e. the process which is directly managed by systemd),
> therefore one get's the fix for free, as this process is stopped by
> systemd.
After typing systemctl disable ssh.service and systemctl enable
ssh.socket, I still have a running sshd -D, and rebooting the system
results in a hanging shell.
After the reboot, there is no sshd -D under systemd, my connection
closes immediately after typing shutdown -r now, but the shutdown
message is still not printed. I can therfore not be sure whether it
was a random ion storm in the kernel that disconnected me or the
shutdown that I initiated.
> > If this is really seriously meant that way, people will see this as a
> > conspiracy to coax people into using socket activation.
> There is no conspiracy, the default mode of ssh is still the daemon
> based.
You know that, I know that. But if the daemon mode has new
shortcomings compared to what we are used to, and the canonical answer
is "switch to socket activation", we're screwed.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420
Reply to: