Я спробував запустити скрипт оболонки через віддалений сеанс, який запускає процес у фоновому режимі за допомогою команди.

nohup python3 run.py > nohup.out &

Коли віддалений сеанс закритий, процес вбивається повідомленням:

Захоплений сигнал SIGHUP

SIGHUP спійманий, але не демонізований. Вихід.

Я не розумію; чому процес загибелі, коли його запускали у фоновому режимі за допомогою nohup & ?

background-process nohup

— Найпотрібніші Мані
джерело

Мене колись бентежила вся несподівана поведінка контролю роботи оболонки. Тепер я просто використовую tmuxі ігнорую nohupабо відхиляюсь або виконуючи фонове завдання повністю.

— Сіюань Рен

Ваша програма Python скасовує `nohup`.

nohupігнорує сигнал зависання, SIG_IGNа потім ланцюг завантажує вашу програму в тому ж процесі.

Ваша програма Python негайно скидає обробку сигналу для сигналу відключення, встановивши власний обробник сигналу. Цей обробник перевіряє внутрішню функцію (це не дуже добре розроблено, спираючись на деякі хибні припущення, якщо це саме те, що я бачив), і вирішує, що відповідний хід дій при отриманні сигналу про повірку - це надрукувати це повідомлення і вихід.

Ваша програма Python за задумом не працює nohup. У системі з оболонкою управління роботою та POSIX-сеансом / семантикою завдань вам потрібно виконати disownзавдання, щоб оболонка ніколи не знала про нього, щоб в першу чергу надсилати на нього сигнал зависання.

(Навіть цього недостатньо для системних операційних систем. Оскільки систематизовані люди трохи відробили вухо свого механізму сеансу входу в простір користувачів, вам також потрібно переконатися, що механізм systemd, який сигналізує про відключення системи, а не зависання, сеанси входу при кожному виході також не починаються.)

Подальше читання

— JdeBP
джерело

Це робить їх програма Python, чи це інтерпретатор Python (/ середовище виконання часу) робить це мовчки за їхніми спинами?

— ilkkachu

Крім того, у Mac OS вихід із сеансу ssh вбиває ваші завдання в оболонці, навіть коли ви почали користуватися nohup; не знайшли засіб для цього

— imhotap

Ну, якщо проблема полягає в обробці сигналу, ОП може просто змінити обробник сигналу на обробник, який не вбиває процес. Це повинно працювати незалежно від того, хто встановлює такий обробник сигналу. Я хотів би додати щодо ssh: іноді, навіть якщо процес зберігається в живих, це може мати проблеми. Пару років тому я втратив досить довгий час, намагаючись зрозуміти деякі помилки дозволу, і, врешті-решт, винуватцем був Керберос: коли закрито сеанс ssh, токени минули, і мені довелося створити нові жетони, які використовуватимуться замість цих сесії ssh.

— Бакуріу

@JdeBP Я намагався setsid nohup python3 run.py > nohup.out &, setid вирішив цю проблему. Це правильний підхід?

— Mostwanted Mani

Чому фоновий процес nohup вбивається?

Ваша програма Python скасовує nohup.

Подальше читання

Ваша програма Python скасовує `nohup`.