Почему мой процесс все еще работает после выхода из системы?

После входа в систему sshя набираю эту команду bash:

sleep 50000000000000 &

Тогда я kill -9этот sleepпроцесс в родительском процессе (то есть bash). Затем окно терминала отключается одновременно.

Когда я снова вхожу в систему, я обнаруживаю, что sleepпроцесс еще жив.

Вопрос : Почему sleepпроцесс может выжить, когда я выхожу из системы и терминал закрывается? На мой взгляд, все, кроме демонов и nohupпрограмм, будут убиты во время выхода из системы. Если sleepможно выжить таким образом, значит ли это, что я могу использовать этот метод вместо nohupкоманды?

Tl; др:

Почему sleepпроцесс может выжить, когда я выхожу из системы и терминал закрывается? На мой взгляд, все, кроме демонов и nohupпрограмм, будут убиты во время выхода из системы. Если sleepможно выжить таким образом, значит ли это, что я могу использовать этот метод вместо nohupкоманды?

Если для bashэкземпляра, порожденного порождением, sshне установлена huponexitопция, ни один процесс не будет завершен каким-либо способом при выходе / выходе из системы, и когда эта huponexitопция установлена, использование kill -9в оболочке не является хорошей альтернативой использованию nohupв дочерних процессах оболочки; nohupдочерние процессы оболочки по-прежнему будут защищать их от SIGHUP, не поступающих из оболочки, и даже если это не важно nohup, все же следует отдавать предпочтение, поскольку это позволяет корректно завершить оболочку.

В bashесть опция называется huponexit, что если набор сделает bashSIGHUP своих детей при выходе / выходе из системы;

В интерактивных экземплярах без входа в систему bash , например в bashэкземпляре, созданном пользователем gnome-terminal, эта опция игнорируется; установлен ли huponexitили не установлен, bashдети никогда не будут вздыхать bashпри выходе;

В случаях интерактивного входа в систему, bash например, в bashэкземпляре, созданном пользователем ssh, эта опция не игнорируется (однако по умолчанию она не установлена); если huponexitустановлено, bashто потомки SIGHUP будут изменены bashпри выходе / выходе из системы; если huponexitне установлено, bashто потомки не будут SIGHUPdup bashпри выходе / выходе из системы;

Таким образом, в общем случае выход / выход из интерактивного bashэкземпляра входа в систему , если huponexitне задана опция, не сделает оболочку SIGHUP дочерними, а выход / выход из интерактивного bashэкземпляра, не входящего в систему , не сделает оболочку SIGHUP дочерними. несмотря на;

Это, однако, не имеет значения в этом случае: использование kill -9 sleepбудет существовать независимо, потому что уничтожение его родительского процесса ( bash) не оставит шансу возможности что- либо сделать с первым (например, если текущий bashэкземпляр был bashэкземпляром входа в систему) и huponexitопция была установлена, чтобы SIGHUP это).

В добавление к этому, в отличие от других сигналов (таких как сигнал SIGHUP, отправляемый bash), сигнал SIGKILL никогда не передается дочерним процессам процесса, следовательно, sleepдаже не уничтожается;

nohupзапускает процесс, невосприимчивый к сигналам SIGHUP, что является чем-то другим; это предотвратит зависание процесса при получении сигнала SIGHUP, который в этом случае может быть получен bashэкземпляром интерактивного входа в систему, если huponexitопция была установлена ​​и оболочка закрыта; поэтому технически использование nohupдля запуска процесса в интерактивном bashэкземпляре входа в систему с huponexitотключенной опцией предотвратит зависание процесса при получении сигнала SIGHUP, но выход / выход из оболочки не будет SIGHUP вне зависимости от этого;

В целом, однако, когда nohupнеобходимо предотвратить поступление сигналов SIGHUP из родительской оболочки, нет причин предпочитать метод kill -9on на родительском методе методом nohupon на дочернем; вместо этого должно быть наоборот.

Убийство родителя с помощью kill -9метода не оставляет шанса для изящного выхода из родительского процесса, в то время как запуск дочернего элемента с помощью nohupметода позволяет завершить родительский процесс другими сигналами, такими как SIGHUP (чтобы создать пример, который имеет смысл в контексте ребенка начали использовать nohup), которые позволяют ему грациозно выйти.

bashпо умолчанию не отправляет сигнал HUP дочерним процессам при выходе . Более подробно (спасибо @kos), он никогда не делает это для не- логинов .

Вы можете настроить bash для этого при входе в систему, если установлен этот параметр huponexit. В терминале выполните:

[romano:~] % bash -l

(это запускает новую оболочку "login")

romano@pern:~$ shopt -s huponexit
romano@pern:~$ sleep 1234 &
[1] 32202
romano@pern:~$ exit
logout

Теперь проверьте sleepпроцесс:

[romano:~] % ps augx | grep sleep
romano   32231  0.0  0.0  16000  2408 pts/11   S+   15:23   0:00 grep sleep

... не работает: он получил сигнал HUP и вышел по запросу.

Если sleepможно выжить таким образом, значит ли это, что я могу использовать этот метод вместо nohupкоманды?

kill -9это действительно не тот путь, по которому нужно идти. Это как стрельба из пистолета в телевизор, чтобы выключить его. Помимо комедийной составляющей здесь нет никаких преимуществ. Процессы не могут поймать или игнорировать SIGKILL. Если вы не дадите процессу завершить то, что он делает, и очистить, он может оставить поврежденные файлы (или другое состояние) и не сможет начать снова. kill -9последняя надежда, когда ничего не работает.

Почему процесс сна может выжить, когда я выхожу из системы и терминал закрыт. На мой взгляд, все, кроме демона и программы nohup, будут убиты при выходе из системы.

Что в вашем случае происходит:

Родительским процессом sleepявляется запущенная bashоболочка. Когда вы используете kill -9bash, процесс bash не имеет возможности отправить a SIGHUPни одному из своих дочерних процессов, потому что SIGKILL(который отправляется kill -9) не может быть перехвачен процессом. Процесс сна продолжается. сон стал бесхозным процессом .

Процесс init (PID 1) выполняет механизм, называемый повторением. Это означает, что процесс init теперь становится родителем этого потерянного процесса. Исключением является init, процессы могут стать его дочерними, так как он собирает процессы, которые потеряли свой исходный родительский процесс. Кстати: демон (как sshd) делает это, когда «в фоновом режиме».

Если этого не произойдет, осиротевший процесс позже (когда закончится) станет процессом зомби. Это то, что происходит, когда waitpid()не вызывается (ответственность родительского процесса, который не может быть выполнен, когда этот процесс был уничтожен). вызовы init waitpid()в определенном интервале, чтобы избежать детей-зомби.

&Запускает процесс в фоновом режиме. Если вы напечатаете ps -ef, вы увидите, что ID родительского процесса (PPID) вашего сна является вашим bash. Затем выйдите и войдите снова. Процесс останется запущенным после выхода из системы. После входа в систему во второй раз вы запустите ps -efснова. Вы увидите, что теперь родитель вашего процесса сна будет обрабатываться с идентификатором "1". Это init, родитель всех процессов.

Использование &заставит программу работать в фоновом режиме. Чтобы увидеть программу в фоновом режиме, используйте bgкоманду и снова запустите ее в качестве переднего плана fg.

Да, есть много способов сохранить работоспособность программы даже при выходе из основного терминала.