nohup vs session vs terminal - что реально происходит после закрытия SSH
Запустили процесс по SSH:
./backup.sh &
Закрыли SSH-сессию - а потом обнаружили, что процесс исчез.
Почему?
Проблема не в самом SSH. Нужно понимать связь между терминалом, session, shell и сигналами.
▪️Что происходит при SSH-подключении
Условно:
sshd
↓
shell
↓
terminal / PTY
↓
команды
Shell создаёт процессы в своей session и process group, а SSH предоставляет им псевдотерминал.
Когда соединение закрывается, терминал исчезает. Это может привести к отправке SIGHUP процессам, связанным с терминалом.
Именно здесь обычный background-процесс может неожиданно завершиться.
▪️& не делает процесс независимым
./backup.sh &
& лишь запускает команду в фоне для текущего shell.
Это не означает, что процесс переживёт закрытие SSH.
Проверить дерево:
ps -o pid,ppid,sid,pgid,tty,stat,cmd
Здесь особенно интересны:
PID PPID SID PGID TTY
Можно увидеть, к какой session и terminal относится процесс.
▪️Что делает nohup
nohup ./backup.sh >backup.log 2>&1 &
nohup не создаёт магическую «вечную» копию процесса.
Он в первую очередь меняет обработку SIGHUP и перенаправляет стандартные потоки, если они всё ещё связаны с терминалом.
Проверить:
ps -o pid,ppid,sid,pgid,tty,cmd -p
Процесс всё ещё может находиться в той же session.
Но получение SIGHUP уже не должно завершить его обычным способом.
▪️А что такое session
Session - это уровень выше process group.
У неё есть лидер - обычно shell, запущенный после входа по SSH.
Посмотреть:
ps -o pid,ppid,sid,pgid,tty,cmd
Например:
PID PPID SID PGID TTY
1000 900 1000 1000 pts/0
1050 1000 1000 1050 pts/0
Оба процесса находятся в одной session, хотя имеют разные process groups.
▪️Почему setsid - это уже другое
Можно создать новую session:
setsid ./backup.sh
Теперь процесс не находится в старой session SSH.
Это уже принципиально отличается от простого:
./backup.sh &
Но для полноценного фонового запуска всё равно нужно учитывать stdin/stdout/stderr и дальнейшее поведение приложения.
▪️Практический вариант
Если нужен простой запуск долгой команды:
nohup ./backup.sh backup.log 2>&1 &
Если нужна полноценная интерактивная среда, которая переживает отключение SSH:
tmux
В tmux процесс продолжает работать внутри отдельной terminal/session среды, а вы можете подключиться к ней позже.
▪️Важный нюанс
nohup, setsid и tmux решают разные задачи.
& → background job
nohup → защита от SIGHUP + перенаправление потоков
setsid → новая session
tmux → отдельная управляемая terminal session
Поэтому вопрос «почему процесс умер после выхода из SSH?» лучше начинать не с nohup, а с:
ps -o pid,ppid,sid,pgid,tty,stat,cmd
Сначала смотрим, к какой session, process group и terminal он вообще был привязан.
BashTex 📱 #bash #systemd
Запустили процесс по SSH:
./backup.sh &
Закрыли SSH-сессию - а потом обнаружили, что процесс исчез.
Почему?
Проблема не в самом SSH. Нужно понимать связь между терминалом, session, shell и сигналами.
▪️Что происходит при SSH-подключении
Условно:
sshd
↓
shell
↓
terminal / PTY
↓
команды
Shell создаёт процессы в своей session и process group, а SSH предоставляет им псевдотерминал.
Когда соединение закрывается, терминал исчезает. Это может привести к отправке SIGHUP процессам, связанным с терминалом.
Именно здесь обычный background-процесс может неожиданно завершиться.
▪️& не делает процесс независимым
./backup.sh &
& лишь запускает команду в фоне для текущего shell.
Это не означает, что процесс переживёт закрытие SSH.
Проверить дерево:
ps -o pid,ppid,sid,pgid,tty,stat,cmd
Здесь особенно интересны:
PID PPID SID PGID TTY
Можно увидеть, к какой session и terminal относится процесс.
▪️Что делает nohup
nohup ./backup.sh >backup.log 2>&1 &
nohup не создаёт магическую «вечную» копию процесса.
Он в первую очередь меняет обработку SIGHUP и перенаправляет стандартные потоки, если они всё ещё связаны с терминалом.
Проверить:
ps -o pid,ppid,sid,pgid,tty,cmd -p
Процесс всё ещё может находиться в той же session.
Но получение SIGHUP уже не должно завершить его обычным способом.
▪️А что такое session
Session - это уровень выше process group.
У неё есть лидер - обычно shell, запущенный после входа по SSH.
Посмотреть:
ps -o pid,ppid,sid,pgid,tty,cmd
Например:
PID PPID SID PGID TTY
1000 900 1000 1000 pts/0
1050 1000 1000 1050 pts/0
Оба процесса находятся в одной session, хотя имеют разные process groups.
▪️Почему setsid - это уже другое
Можно создать новую session:
setsid ./backup.sh
Теперь процесс не находится в старой session SSH.
Это уже принципиально отличается от простого:
./backup.sh &
Но для полноценного фонового запуска всё равно нужно учитывать stdin/stdout/stderr и дальнейшее поведение приложения.
▪️Практический вариант
Если нужен простой запуск долгой команды:
nohup ./backup.sh backup.log 2>&1 &
Если нужна полноценная интерактивная среда, которая переживает отключение SSH:
tmux
В tmux процесс продолжает работать внутри отдельной terminal/session среды, а вы можете подключиться к ней позже.
▪️Важный нюанс
nohup, setsid и tmux решают разные задачи.
& → background job
nohup → защита от SIGHUP + перенаправление потоков
setsid → новая session
tmux → отдельная управляемая terminal session
Поэтому вопрос «почему процесс умер после выхода из SSH?» лучше начинать не с nohup, а с:
ps -o pid,ppid,sid,pgid,tty,stat,cmd
Сначала смотрим, к какой session, process group и terminal он вообще был привязан.
BashTex 📱 #bash #systemd