ru_vds 17 дек 2020 в 16:23

Кунг-фу стиля Linux: организация работы программ после выхода из системы

9 мин

15K

Блог компании RUVDS.comНастройка Linux*Системное администрирование*

Перевод

+34

Комментарии 14

alekciy 17 дек 2020 в 18:29

В современных версиях linux (в ubuntu точно есть) фоновые команды по умолчанию автоматически перепривязываются к init процессу. Поэтому продолжают работу.

alekciy@alekciy-home:$ ssh srv1
root@srv1:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.6 LTS
Release:    16.04
Codename:   xenial
root@srv1:~# for i in `seq 1 10`; do echo $i >> /tmp/txt.log ; sleep 1 ; done &
[1] 22590
root@srv1:~# logout
Connection to srv1 closed.
alekciy@alekciy-home:$ ssh srv1
root@srv1:~# tail -n 1 /tmp/txt.log
10
root@srv1:~#

void_one 17 дек 2020 в 18:42

У нас тут сейчас 2020 год, и в нем современная версия Ubuntu это 20.04 focal. И вот в современных версиях все как раз наоборот: systemd при выходе пользователя из сессии прибивает все процессы, даже фоновые и запущенные всеми перечисленными способами:

Одно время они даже прибивали tmux, и требовали исправить его так, чтобы он соответствовал требованиям systemd: https://news.ycombinator.com/item?id=11797075

Сейчас, вроде бы, с tmux как-то все устаканилось. Но для запуска фонового процесса, который должен остаться работать после выхода из сессии, теперь есть только один работающий метод:

systemd-run <ваш процесс>

alekciy 17 дек 2020 в 19:57

У нас тут в 2020-ом 16LTS версия все еще поддерживаемая. И значит имеет право быть в эксплуатации. Под рукой с ходу есть еще только Ubuntu 18LTS в которой история ровно такая же.
В целом я просто помню, что как раз поведение по умолчанию это завершение фонового процесса при разрыве связи. И много разрабов на этом погорели думая что процесс продолжает работу. И уже после фейла узнавали screen и зачем он. И это поведение относительно недавно изменилось.

P.S. А есть под рукой сервер с 20-ой? Что бы запустить приведенный мною пример.

void_one 17 дек 2020 в 20:58

Все-таки "поддерживаемая" != "современная".

Проверил пример на 18.04 и на 20.04, и он работает: майнтайнеры Ubuntu выставили параметр KillUserProcesses при сборке systemd в "no", http://changelogs.ubuntu.com/changelogs/pool/main/s/systemd/systemd_237-3ubuntu10.38/changelog

saboteur_kiev 18 дек 2020 в 03:20

А что со screen, disown и nohup?

Вообще не очень понятно зачем прибивать фоновые процессы.
Ведь по идее им должен просто sighup отправляться, но если у процесса родитель уже перекинут на init, то и не отправится.

void_one 18 дек 2020 в 03:53

Тоже не работали какое-то время.

Пишут, что однажды что-то наворотили в d-bus и systemd, так что в гноме при выходе процессы перестали закрываться.

"In the normal case it makes a lot of sense to kill remaining processes. The exception is stuff like screen and tmux. But it's easy enough to work around, a simple example was added to the man page in previous commit. In the long run those services should integrate with the systemd users session on their own."

saboteur_kiev 18 дек 2020 в 04:32

Как по мне, то совершенно бредово.

nohup command &
Процесс отвязан от родителя, потоки перенаправлены, как вообще линукс может понять что этот процесс должен быть завершен при закрытии текущей сесиии? По UID пользователя закрывать ВСЕ его процессы?

Или это что, никто не может просто взять и написать свой оконный менеджер (это же просто прикладное приложение), без того, чтобы коммитить в ядро?

Temmokan 18 дек 2020 в 11:00

loginctl enable-linger

void_one 18 дек 2020 в 16:53

Специально только что проверил еще раз на 18.04: как не работало, так и не работает:

в /etc/systemd/logind.conf включил KillUserProcesses=yes (как по умолчанию в systemd upstream), перестартовал systemd-logind.service, перезашел,
включил sudo loginctl enable-linger <мой account>,
проверил пример от alekciy — процесс убило сразу при выходе

Если вернуть "#KillUserProcesses=no", как по умолчанию в Ubuntu, то фоновый процесс опять остается, даже с выключенным linger.