What happens if you connect to the server via SSH to close the terminal without the exit command?

    3 answers 3

    The running process will receive a hup signal.

    what will happen next - it depends entirely on what the developers have invested in the program. by default it should complete.

    script to check:

    #!/bin/bash trap 'touch hupped; exit' hup echo $$ while :; do sleep 1; echo -n .; done

    first, it prints the number of its process, and then once a second it gives the dot character to stdout . when the hup signal is received, it creates a hupped file in the current directory and exits.

      If the terminal is completed correctly, it sends a command to close the ssh connection, then the hup signal is sent to all processes. If the terminal process is killed, the operating system sends a tcp-fin packet, an exception occurs on the server, then hup. If the connection was broken incorrectly, for example, the network disconnected, then fin will not reach and the process will be performed for some time (usually about half an hour) until the connection is broken by the server. Further, as in other cases, hup.

      • Break the connection on a timeout so that it turns out hup, only the server can, not the router. - Pavel Mayorov
      • checked, not tearing. - eri

      Upon the closing of the controlling terminal, bash receives a SIGHUP and exits , [in the interactive case], sending a signal to all processes from its task list. Stopped tasks also get SIGCONT. From the bash documentation on signals (which corresponds to the expected behavior of groups of processes created using setpgid(2) ):

      The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent to ensure that they receive the SIGHUP. It has been noted that it has been shown that it has been disassembled, for example, using disown-it.

      nohup allows you to ignore the SIGHUP signal, disown command allows you to exclude a task from this list. The systemd 230 version changes the default behavior when a user session ends.

      The ssh process on the client receives a SIGHUP . ssh, when receiving a signal, restores stdin, if necessary, forwards the signal to the proxy command, if any, and exits . Aside, normally, with normal bash output (exit, Ctrl-D ), SIGHUP will not be sent to tasks, since the huponexit option is disabled by default. In which case you are not logged out?

      In this case, the server may not immediately find out that the ssh client is dead. Does getting disconnected from an SSH session kill your programs? When sshd on the server notices that the connection is dead, this results in sending a SIGHUP signal already on the server and repeating the behavior from the quote above.

      • thanks, but very difficult - user208916
      • @Hipster: you have already been given simplified answers. Even my answer is a simplification of what you can actually meet (it describes the situation: you closed the GNOME terminal window in which you had bash running, in which ssh was interactively running, which entered the system on that side also in bash). For example, the presence of a terminal locally does not say that it should be allocated remotely as well. Or the behavior may vary depending on the software version. All these details start to matter when you want to know “why this process died / did not die when the terminal was closed.” - jfs