Bug #626
closed
System reboot does not disconnect ssh sessions
Added by Jochen Becker over 14 years ago. Updated over 14 years ago.
100%
Description
if you were logged in via ssh and the system reboots, the connection will not be reseted by the ssh server like a normal unix or linux
Updated by Chris Buechler over 14 years ago
- Status changed from New to Rejected
- FINAL System shutdown message from root@pfs-1.2-test1.esx.buechler.local *
*
System going down IMMEDIATELY
if you reboot via a SSH session, same. Regardless of how you reboot, it kills your SSH sessions. It behaves exactly the same as a stock FreeBSD.
Updated by Jochen Becker over 14 years ago
if i upgrade via the console at the end the system reboots and the ssh session will not be closed or terminated
my ssh-console window stands, because the server (pfsense box) is lost.
the only way to close my terminal window is to kill ist or to kill my local sshclientprocess.
Updated by Chris Buechler over 14 years ago
That does not happen for me on Windows, OS X, BSD nor Linux. If you find something that is specifically wrong that is causing this, we can look at changing it. It sounds like a client issue, or who knows what, but definitely not the normal behavior nor what I have ever seen across many systems and platforms.
Updated by Henrik Kaare Poulsen over 14 years ago
I can confirm this issue.
When halting a "vanilla" FreeBSD system, an RST package (TCP/IP) is send by the server to close the SSH connection.
When halting pfSense (from serial console or ssh; I have not tried from GUI), no RST package is send, hence the client terminal hangs.
This happens on any pfSense 2.0 snapshot I can remember using.
(As the issue is confirmed "on the wire", I do not think it is client related. However, for the record, my clients are different versions of gnome terminal on different versions of ubuntu).
A guess: a "vanilla" FreeBSD uses /etc/rc.d/sshd which sends sshd a SIGTERM to stop it.
Could it be that the pfSense setup (either explicitly or as part of default FreeBSD shutdown) sends SIGKILL instead?
Updated by Jim Pingle over 14 years ago
- Status changed from Rejected to New
I do see this happen on reboot, but not halt, though I suspect that is a side effect of VMware disconnecting the NICs when it shuts down and not the OS.
Oddly enough, if I force sshd to stop from the console, it also does not disconnect my SSH sessions, though a "killall -TERM sshd" does the job.
Updated by Jim Pingle over 14 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 99f4210976a05e0450ab6d5df2b7c8cf87c29099.
Updated by Henrik Kaare Poulsen over 14 years ago
I am sorry, but I am not able to check the changeset at the moment.
However, two clarifications:
1) Most of the time I do reboot, not halt. So when I wrote "halt" it was not entirely precise. I usually do reboot from ssh or console.
2) I am running pfSense on a Soekris box, so no VMware issues here
Updated by Jim Pingle over 14 years ago
- Status changed from Feedback to New
I thought I had it fixed but this still isn't quite right. There's a bit of a chicken-and-egg problem in the shutdown sequence. If we kill ssh, it doesn't execute the later steps, but if you reorder it, the sessions won't be terminated.
The problem seems to be that on reboot, the interfaces are downed before shutdown is run. If the interfaces are left up, ssh sessions terminate as they should.
Updated by Jim Pingle over 14 years ago
- Status changed from New to Feedback
Applied in changeset 2d99dce73be4d5c020f8e6bdbbb61bc2e52fdd4c.
Updated by Jochen Becker over 14 years ago
via ssh login an upgrade via url
1st
upgrade to pfSense-2.0-BETA1-4g-20100603-0608-nanobsd-upgrade.img.gz
and after this
upgrade to the same pfSense-2.0-BETA1-4g-20100603-0608-nanobsd-upgrade.img.gz
result
- FINAL System shutdown message from admin@pfsense ***
System going down IMMEDIATELY
Connection to <ip> closed by remote host.
Connection to <ip> closed.
so the fix works
thx
Updated by Chris Buechler over 14 years ago
- Status changed from Feedback to Resolved