Редагувати для 2016 року:
Це запитання передує системному дебаліку v230 . Як і для systemd v230, новим замовчуванням є вбивство всіх дітей завершеного сеансу входу, незалежно від того, які історично обгрунтовані запобіжні заходи були вжиті для запобігання цьому. Поведінка може бути змінено шляхом установки KillUserProcesses=noв /etc/systemd/logind.confабо обійти з допомогою Systemd конкретних механізмів для запуску демона в просторі користувача. Ці механізми виходять за рамки цього питання.
У тексті нижче описано, як традиційно працювали речі в дизайнерській області UNIX довше, ніж існувало Linux.
Вони будуть вбиті, але не обов’язково негайно. Залежить від того, скільки часу потрібно, щоб демон-SSH вирішив, що ваш зв’язок мертвий. Далі йде довше пояснення, яке допоможе зрозуміти, як це насправді працює.
Коли ви ввійшли в систему, демон SSH виділив для вас псевдотермінал і додав його до налаштованої оболонки входу вашого користувача. Це називається контрольним терміналом. Кожна програма, яку ви розпочали нормально в цей момент, незалежно від того, скільки глибоких шарів снарядів, в кінцевому рахунку простежить своє походження назад до цієї оболонки. Ви можете спостерігати за цим за допомогою pstreeкоманди.
Коли процес демон демонів SSH, пов'язаний з вашим з'єднанням, вирішить, що ваше з'єднання мертве, він надсилає сигнал зависання ( SIGHUP) в оболонку входу. Це сповіщає оболонку, яку ви зникли, і що вона повинна починати очищення після себе. У цей момент відбувається специфічна оболонка (шукайте на її документації на сторінці "HUP"), але здебільшого вона почне надсилати SIGHUPна запущені завдання, пов'язані з нею, перед тим, як припинити. Кожен з цих процесів, у свою чергу, буде робити все, що вони налаштовані робити при отриманні цього сигналу. Зазвичай це означає припинення. Якщо у цих робочих місць є власні завдання, сигнал також часто передається.
Процеси, які переживають завис керуючого терміналу, - це ті, що або відмежовували себе від терміналу (демонові процеси, які ви запустили всередині нього), або ті, на які було викликано префіксовану nohupкоманду. (тобто "не зациклюйся на цьому") Демони трактують сигнал HUP по-різному; оскільки вони не мають керуючого терміналу і не отримують автоматично сигнал HUP, він замість цього перераховується як запит адміністратора вручну перезавантажити конфігурацію. За іронією долі це означає, що більшість адміністраторів не вивчають "зависання" використання цього сигналу для недемонів набагато пізніше. Ось чому ти це читаєш!
Термінальні мультиплексори - це поширений спосіб зберегти ваше середовище оболонки недоторканим між відключеннями. Вони дозволяють вам відірватися від ваших процесів оболонки таким чином, що ви зможете повторно приєднатись до них пізніше, незалежно від того, чи було це відключення випадковим чи навмисним. tmuxі screenє більш популярними; синтаксис їх використання виходить за рамки вашого питання, але їх варто вивчити.
Мені було запропоновано розібратися, скільки часу потрібно, щоб демон SSH вирішив, що ваш зв’язок мертвий. Це поведінка, яка характерна для кожної реалізації демона SSH, але ви можете розраховувати, що всі вони припиняться, коли будь-яка сторона скидає з'єднання TCP. Це станеться швидко, якщо сервер намагається записати в сокет, а пакети TCP не будуть підтверджені, або повільно, якщо нічого не намагається записати в PTY.
У цьому конкретному контексті найімовірнішими факторами, які викликають запис, є:
- Процес (як правило, на передньому плані), який намагається записати в PTY на стороні сервера. (сервер-> клієнт)
- Користувач намагається записати на PTY на стороні клієнта. (клієнт-> сервер)
- Голівки будь-якого сорту. Зазвичай вони не включені за замовчуванням ні клієнтом, ні сервером, і, як правило, є два варіанти: рівень програми та на основі TCP (тобто
SO_KEEPALIVE). Keepalives дорівнює або серверу, або клієнту, нечасто надсилаючи пакети в іншу сторону, навіть коли нічого в іншому випадку не буде причин писати в сокет. Хоча це, як правило, призначене для спідниці між брандмауерами, які занадто швидко вичерпують з'єднання, це має додатковий побічний ефект, завдяки чому відправник помічає, коли інша сторона не реагує на це набагато швидше.
Тут застосовуються звичайні правила для сеансів TCP: якщо між клієнтом і сервером відбувається переривання зв’язку, але жодна сторона не намагається надіслати пакет під час проблеми, з'єднання збережеться за умови, що обидві сторони будуть реагувати згодом і отримувати очікуваний TCP порядкові номери.
Якщо одна сторона вирішила, що сокет мертвий, ефекти, як правило, негайні: процес sshd відправить HUPі самозавершиться (як описано раніше), або клієнт повідомить користувача про виявлену проблему. Варто зазначити, що те, що одна сторона вважає, що друга мертва, не означає, що іншу про це повідомляють. Осиротіла сторона зв'язку, як правило, залишається відкритою до тих пір, поки вона не спробує записати її та вимкнути час, або не отримає скидання TCP з іншої сторони. (якщо підключення було доступне в той час) Очищення, описане в цій відповіді, відбувається лише після того, як сервер помітив.
screen, спробуйте перезапустити .