Bug 1023788

I am seeing the same issue.

Thanks

nathan

I can reproduce this issue using network.service instead of NetworkManager.service. And it incidentally works with nm.service because nm doesn't shut a network interface down on stop. The problem with ssh session is that should be killed only on shutdown/reboot and they shouldn't be killed at sshd stop, network stop and so.

Following unit works for me as a workaround:

# cat /etc/systemd/system/sshd-shutdown.service 
[Unit]
Description=kill all sshd sessions
Requires=mutil-user.target

[Service]
ExecStart=/usr/bin/killall sshd
Type=oneshot

[Install]
WantedBy=shutdown.target reboot.target poweroff.target

i know that they should not be killed and sshd restart/stop and network restart but that doe snot change the fact that it is a regression because on F18/F19 there is no problem

sshd.service are same on f18 and f19. So, as you wrote, it's probably related to something else than openssh itself and I'm still looking for it. I started with the sshd-shutdown.service unit as it might be one of solutions how to workaround random future changes in the systemd or network services.

pretty sure systemd, the same happens on RHEL7 public-beta

I am seeing this on RHEL 7 beta as well, filed https://bugzilla.redhat.com/show_bug.cgi?id=1047614.

this seems to be the same as https://bugzilla.redhat.com/show_bug.cgi?id=626477

To cancel the ssh connection on the client side, type "~" followed by ".", this way, you don't need to kill the ssh client. If it does not work in the first place, press enter and repeat the sequence "~.".

and *when* will we see a fix for that?

* this was reported *long* before F20 final release
* this can be reproduced with *every* reboot and shutdown

this did not happen in *any* fedora systemd-release and some magic sequences are only a dirty workaround for things which have to work out-of-the-box unquestinable and never made it in a final release or even through a beta-QA

(In reply to Petr Lautrbach from comment #2)
> I can reproduce this issue using network.service instead of
> NetworkManager.service. And it incidentally works with nm.service because nm
> doesn't shut a network interface down on stop. The problem with ssh session
> is that should be killed only on shutdown/reboot and they shouldn't be
> killed at sshd stop, network stop and so.
> 
> Following unit works for me as a workaround:
> 
> # cat /etc/systemd/system/sshd-shutdown.service 
> [Unit]
> Description=kill all sshd sessions
> Requires=mutil-user.target
> 
> [Service]
> ExecStart=/usr/bin/killall sshd
> Type=oneshot
> 
> [Install]
> WantedBy=shutdown.target reboot.target poweroff.target

This workaround fixed my problem on our testing VMs that are rebooted per test-case and were hanging continiously and failing to reboot using virsh shutdown and virsh start.

Thanks Petr and Harald!

I do hope this bug will get resolved properly soon.

yes, the workaround does what it is supposed to do
frankly i will continue to have it installed forever

why? because i do not trust systemd and sshd in combination any longer after that and some fedora-releases before where "yum distro-sync" and complete-transaction each time killed teh current ssh-session (the opposite of now) while ssh, reboots and ssh and dist-upgrades *never* was a problem before F15/F17

As per #c2 and #c9, I created:

vim /etc/systemd/system/sshd-shutdown.service 
====
[Unit]
Description=kill all sshd sessions
Requires=mutil-user.target

[Service]
ExecStart=/usr/bin/killall sshd
Type=oneshot

[Install]
WantedBy=shutdown.target reboot.target poweroff.target
====

Then:

systemctl daemon-reload
systemctl enable sshd-shutdown.service
====
ln -s '/etc/systemd/system/sshd-shutdown.service' '/etc/systemd/system/shutdown.target.wants/sshd-shutdown.service'
ln -s '/etc/systemd/system/sshd-shutdown.service' '/etc/systemd/system/reboot.target.wants/sshd-shutdown.service'
ln -s '/etc/systemd/system/sshd-shutdown.service' '/etc/systemd/system/poweroff.target.wants/sshd-shutdown.service'
====

After this, I shut down and the terminal closed properly.

(In reply to digimer from comment #11)
> Requires=mutil-user.target

BTW at least for me, this "mutil" typo is essential for this hack to work. Do the s/mutil/multi/ fix or remove the whole line and it no longer does. Too lazy at the moment to figure out why, just did s/mutil/doesnt-exist/ locally to make it more clear and moving on...

confirmed and makes systemd of F20/RHEL7 even more questionable because what crazy bahvior is it to rely on a typo? normally it should do the same without this line as with a non-existing target

what about the systemd guys waking up to fix this odd behavior at the root-cause and while the are at it debug how this rely-on-error can be possible at all?!?!

in the meantime https://bugzilla.redhat.com/show_bug.cgi?id=1047614 for RHEL7 became "urgent" and "critical" - but who am i to qualify that such bugs make it in a release even if they are reported before GA and not fixed within 3 months...

*** This bug has been marked as a duplicate of bug 626477 ***

This is marked as a duplicate of a ~3.5 year old bug... Does that not complicate resolving it today? Will this (regression?) be fixed?

and the main question: why doe sthe problem re-appear
this is *not* a duplicate
this is an new regression in F20/RHEL7 as long the old
fix did not get removed completly for whatever reason

systemd-210-2.fc21.x86_64 is fixing that behavior, well, hopefully F20 will get systemd-210 soon - unsure how to verify if it also fixes the "rely-on-typo-behavior" from https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c12