4 ms·

As I remember, `login` program (that asks for your login and password on terminal) does a "virtual hangup" to prevent such things.

cryptonector 8y ago
Well, on *BSD the way this works is that when the session leader exits the pty/tty will internally call vhangup(2), which in turn does all that revoke(2) does on the tty FD plus it sends SIGHUP to any processes with that tty as the controlling tty. Linux for a long time had nothing like this. It has a vhangup(2), but looking at its implementation it doesn't seem to do what the BSD vhangup(2) does by calling revoke(2): replace all open file descriptors pointing to the tty with one that returns EIO for read(2)/write(2)/etc. Linux does NOT have a revoke(2), or at least I can't find it. There was a patch for that back in 2006 and 2007. I don't know what happened to that. EDIT: Some trivia as well. On BSD SIGHUP is generated by the tty. On Linux and Solaris/Illumos it's only generated by the session leader process on exit, and only if it wants to. This is how bash's disown builtin works: it just doesn't HUP the disown background jobs. The C shell (csh) historically never generated SIGHUP because it's a BSD shell. Back in the early aughts there was some controversy where csh users wanted OpenSSH's sshd to close a session when the pty session leader exits, as otherwise the session would stay open indefinitely. The OpenSSH developers feared this would lose data, and they were right. The source of this problem was that csh wasn't generating SIGHUP on Solaris and Linux, so background jobs stayed alive and held an open file reference to the pty, which meant that they kept sshd from seeing EOF on the ptm, so sshd would not terminate the session as long as those bg jobs stayed alive. This is all still the case today.
- cat199 8y ago
  Oooh so thats why my terminals would get hungup on linux machines when I logged out with a bg job.. and why I haven't seen it since switching to MacOS or OpenBSD for most logins to other systems :) thanks :D
  - cryptonector 8y ago
    You're welcome. I think it's pretty shocking that there's not yet a revoke(2) for all these systems. If there was, then sshd could revoke(2) the pts when the session leader exits, then wait for EOF, and then close the session. Also, please stop using the C shell. It's a shell that sucks. Granted, they all kinda suck, but the C shell more than all the rest. :) EDIT: Oh, and to be clear, this is about the server-side of ssh. That you're using OS X on the client-side makes no difference.
- caf 8y ago
  When a tty is hung up on Linux, the file operations of all open file structures associated with it are replaced with hung_up_tty_fops, which means all subsequent read(2) returns 0 (EOF), write(2) returns EIO and ioctl(2) returns ENOTTY or EIO. This is basically a tty-specific implementation of revoke(2). Also, when the session leader exits on Linux, the kernel does send SIGHUP and SIGCONT to session leader's process group and the foreground process group (this is in tty_signal_session_leader()).
  - cryptonector 8y ago
    Oh, that must be pretty new (relative to the early aughts anyways). Sorry I missed it.
tedunangst 8y ago
That would be rather inconvenient here, as you would return to the root shell and find it unresponsive to input.

cryptonector 8y ago

Well, on *BSD the way this works is that when the session leader exits the pty/tty will internally call vhangup(2), which in turn does all that revoke(2) does on the tty FD plus it sends SIGHUP to any processes with that tty as the controlling tty. Linux for a long time had nothing like this. It has a vhangup(2), but looking at its implementation it doesn't seem to do what the BSD vhangup(2) does by calling revoke(2): replace all open file descriptors pointing to the tty with one that returns EIO for read(2)/write(2)/etc. Linux does NOT have a revoke(2), or at least I can't find it. There was a patch for that back in 2006 and 2007. I don't know what happened to that. EDIT: Some trivia as well. On BSD SIGHUP is generated by the tty. On Linux and Solaris/Illumos it's only generated by the session leader process on exit, and only if it wants to. This is how bash's disown builtin works: it just doesn't HUP the disown background jobs. The C shell (csh) historically never generated SIGHUP because it's a BSD shell. Back in the early aughts there was some controversy where csh users wanted OpenSSH's sshd to close a session when the pty session leader exits, as otherwise the session would stay open indefinitely. The OpenSSH developers feared this would lose data, and they were right. The source of this problem was that csh wasn't generating SIGHUP on Solaris and Linux, so background jobs stayed alive and held an open file reference to the pty, which meant that they kept sshd from seeing EOF on the ptm, so sshd would not terminate the session as long as those bg jobs stayed alive. This is all still the case today.

cat199 8y ago
Oooh so thats why my terminals would get hungup on linux machines when I logged out with a bg job.. and why I haven't seen it since switching to MacOS or OpenBSD for most logins to other systems :) thanks :D
- cryptonector 8y ago
  You're welcome. I think it's pretty shocking that there's not yet a revoke(2) for all these systems. If there was, then sshd could revoke(2) the pts when the session leader exits, then wait for EOF, and then close the session. Also, please stop using the C shell. It's a shell that sucks. Granted, they all kinda suck, but the C shell more than all the rest. :) EDIT: Oh, and to be clear, this is about the server-side of ssh. That you're using OS X on the client-side makes no difference.
caf 8y ago
When a tty is hung up on Linux, the file operations of all open file structures associated with it are replaced with hung_up_tty_fops, which means all subsequent read(2) returns 0 (EOF), write(2) returns EIO and ioctl(2) returns ENOTTY or EIO. This is basically a tty-specific implementation of revoke(2). Also, when the session leader exits on Linux, the kernel does send SIGHUP and SIGCONT to session leader's process group and the foreground process group (this is in tty_signal_session_leader()).
- cryptonector 8y ago
  Oh, that must be pretty new (relative to the early aughts anyways). Sorry I missed it.

tedunangst 8y ago

That would be rather inconvenient here, as you would return to the root shell and find it unresponsive to input.