tmux сесія загинула під час відключення від ssh

Резюме : Я намагаюся з’ясувати, чому мій сеанс tmux вмирає, коли я відключаюсь від ssh

Деталі :

У мене встановлений tmux в системі Arch Linux. Коли я запускаю tmux сеанс, я можу відключитися від нього та знову приєднатись, поки активна сесія ssh. Але якщо я закінчу свою сеанс ssh, тоді сесія tmux вбивається.

Я знаю, що це не нормальна поведінка, тому що у мене є інша система, де сеанс tmux продовжується, навіть якщо сеанс ssh закінчився, і я можу приєднатися до сесії tmux після встановлення нового з'єднання ssh. Система, у якої є проблема, і та, яка працює правильно, мають дуже схожі конфігурації, тому я не знаю, що перевірити.

Я запускаю tmux версії 1.9a. Система, у якої є проблема (до якої я маю кореневий доступ), має версію ядра Linux 3.17.4-1, а система, яка працює правильно, має версію ядра 3.16.4-1-ARCH (у мене немає цього коріння система). Я сумніваюся, що версія ядра є джерелом проблеми, але я помітив лише одну різницю.

Я думав, що попросив би побачити, чи хтось бачив подібну проблему і знає можливе рішення.

Точні кроки, які призводять до проблеми:

1. ssh to machine
2. запустіть tmuxдля запуску tmux
3. ctrl-B D від'єднатись (у цей момент я міг би повторно долучитися tmux attach
4. закрити ssh-сеанс (у цей момент сесія tmux вбита, я міг спостерігати це, коли я входив як root у іншому терміналі)
5. відновіться до ssh і запустіть, tmux attachі я отримаю повідомлення no sessionsта працює, tmux lsповертається failed to connect to server: Connection refused. Це має сенс, оскільки сервіс не працює. Що для мене не має сенсу, це те, що він вбивається на кроці 4, коли я відключаюсь від сеансу ssh.

Дані про напругу:

У відповідь на один із коментарів я використав strace, щоб побачити, які системи викликає процес сервера tmux. Схоже, коли я виходжу з сеансу ssh (набравши exitабо за допомогою ctrl-d), процес tmux вбивається. Ось фрагмент заключної частини виведення страз.

poll([{fd=4, events=POLLIN}, {fd=11, events=POLLIN}, {fd=6, events=POLLIN}], 3, 424) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
sendto(3, "\17", 1, 0, NULL, 0)         = 1
+++ killed by SIGKILL +++

Я порівняв це з іншою системою, де tmux працює належним чином, і в цій системі процес tmux продовжує працювати навіть після того, як я вийду. Отже, першопричиною виявляється те, що процес tmux припиняється, коли я закриваю сеанс ssh. Мені потрібно буде витратити деякий час на вирішення цього питання, щоб з'ясувати, чому, але я подумав, що оновлю своє питання, оскільки пропозиція про напругу була корисною.

Теорія

Деякі системи init, включаючи systemd, забезпечують можливість знищення всіх процесів, що належать до сервісу. Служба, як правило, запускає єдиний процес, який створює більше процесів шляхом розгортання, і ці процеси також можуть це робити. Усі такі процеси, як правило, вважаються частиною послуги. У systemd це робиться за допомогою cgroups .

У systemd всі процеси, що належать до послуги, вбиваються при зупинці служби за замовчуванням. Сервер SSH, очевидно, є частиною сервісу. Під час підключення до сервера SSH-сервер зазвичай розщеплюється, а новий процес обробляє ваш сеанс SSH. Шляхом відключення з процесу сеансу SSH або його дітей, починаються інші процеси на сервері, включаючи ваш екран або tmux .

Активація Killmode та socket

Поведінка за замовчуванням може бути змінена за допомогою KillModeдирективи. Проект висхідного потоку не включає AFAIK жодних .serviceфайлів, тому файли залежать від поширення. Зазвичай існує два способи включення SSH у вашій системі. Один - це класика, ssh.serviceяка підтримує тривале прослуховування демона SSH в мережі. Інший - через активацію сокета, яку обробляє той, ssh.socketякий по черзі запускається, sshd@.serviceякий працює лише для одного сеансу SSH.

Рішення

Якщо ваші процеси вбиваються в кінці сеансу, можливо, ви використовуєте активацію сокета, і він вбивається системою, коли помічає, що процес сеансу SSH закінчується. У цьому випадку є два рішення. Перше - уникати використання активації сокета, використовуючи ssh.serviceзамість цього ssh.socket. Інше - встановити KillMode=processв Serviceрозділі ssh@.service.

Цей KillMode=processпараметр також може бути корисним для класичного ssh.service, оскільки це дозволяє уникнути порушення процесу сеансу SSH або екрану чи tmux процесів, коли сервер зупиняється або перезапускається.

Майбутні нотатки

Ця відповідь, очевидно, набула рівня популярності. Хоча він працював на ОП, може статися, що він не працює для когось у майбутньому через розробку або конфігурацію системного входу . Перевірте документацію про сеанси реєстрації, якщо ви відчуваєте поведінку, відмінну від опису в цій відповіді.

Чи використовуєте ви systemd з активацією сокета для SSH?

Якщо так, то з цим відома проблема . На думку прихильників systemd, це насправді особливість - systemd вбиває всі процеси, породжені сеансом, коли сеанс припиняється. (Я можу бачити, що це корисно, але в GNU screen, або tmux, ви, звичайно, цього не хочете. Ні в більшості інших випадків, коли користувачі можуть запускати фонові процеси, звичайно.)

Якщо так, спробуйте переключитися sshd.socketнаsshd.service .

У мене були ті ж проблеми з tmux і екраном на Ubuntu 16.04 (kde neon). Коли сеанс ssh був відключений, екран / tmux припинявся.

Коротше кажучи, systemd змінив налаштування за замовчуванням на killuserprocess = так, після виходу з сеансу ssh кожен створений ним процес буде припинено.

За допомогою цієї команди легко виправити (після години спроб) запустити екран / tmux

Для екрана

systemd-run --scope --user screen

для Tmux

systemd-run --scope --user tmux

Ви можете створити псевдонім, щоб зробити його простіше

alias tmux= "systemd-run --scope --user tmux"

Ще одне рішення цього питання, яке не потребує переходу sshd.socketна sshd.service, - це запуск tmuxсервера як системної служби [0]. Таким чином, tmuxсервер вже працює, коли ви SSH на сервері, замість того, щоб породжуватися tmuxкомандою в SSH, таким чином не буде вбито.

[0] https://wiki.archlinux.org/index.php/tmux#Autostart_with_systemd

Найкраща відповідь, яку я знайшов, IMO, дається на Prevent Logoff from Killing tmux Session :

Це «особливість» існувала в systemdраніше, але ці systemdрозробників вирішили провести зміни в значеннях за замовчуванням , щоб включити параметр для припинення дочірніх процесів при виході з сеансу.

Ви можете скасувати це налаштування у logind.conf( /etc/systemd/logind.conf):

KillUserProcesses=no