У яких випадках SIGHUP не надсилається на роботу при виході з системи?


10

Я прочитав відповідь від користувача, який стверджував, що працює

foo 2>&1 >& output.log &

це призведе до fooпродовження роботи навіть під час виходу з системи. За словами цього користувача, це навіть працювало над SSH-з'єднаннями.

Я не дуже вірив у це, оскільки був у мене під враженням, що у випадку відключення від SSH або припинення TTY, оболонка і, отже, її процеси отримають SIGHUP, внаслідок чого вони припиняються. Це, на мій припущення, було єдиною причиною використання nohupв таких випадках, або tmux, screenта ін.

Потім я заглянув у керівництво glibc :

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

Це ніби підтверджує мої думки. Але дивлячись далі, воно говорить :

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

Отже, чи означає це, що робочі місця, викладені у фоновому режимі, не отримають SIGHUP?

На мій подальший плутанина, я запустив інтерактивну сесію Zsh, запустив yes >& /dev/null &і набрав текст exit, коли Zsh попередив мене, що я exitпрацюю , і після друку вдруге сказав мені, що ВИДАЛИ одну роботу. Виконувати точно так само в Bash залишає роботу запущеною ...


У мене в минулому були проблеми з сервером, який раптово відключається через ssh, і мій процес просто продовжував працювати, але без жодних tty, пов'язаних, тому мені довелося знову увійти та відправити SIGHUP / TERM / KILL, щоб закінчити їх. Отож, дотримуючись тієї ж логіки, я перевірив саме зараз, набрав logoutі yesвсе ще працює.
Брайам

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

Ви посилаєтесь на це запитання: serverfault.com/questions/115999/… ? Відповідь, здається, знайдеться там - це параметр RedHat не встановлений за замовчуванням. Це специфічна конфігурація RedHat.
Борис Бурков

@Bob Ні, я цього раніше не бачив, але це хороший ресурс. Дякую!
slhck

Радий, що це допомогло. Насправді Рафаель також посилається на це питання.
Борис Бурков

Відповіді:


18

Схоже, Bash надсилає SIGHUPєдине, якщо воно отримало самовідвід SIGHUP, який, наприклад, відбувається, коли віртуальний термінал закритий або коли з'єднання SSH перерване. З документації :

Оболонка виходить за замовчуванням після отримання SIGHUP. Перед виходом інтерактивна оболонка надсилає SIGHUP на всі завдання, запущені або зупинені. Зупинені завдання надсилаються SIGCONT, щоб переконатися, що вони отримують SIGHUP. Щоб оболонка не посилала сигнал SIGHUP на певну роботу, її слід видалити з таблиці завдань із відключеним вбудованим (див. Вбудовані контролі за роботою) або позначити, щоб не отримувати SIGHUP за допомогою відключення -h.

Отже, якщо ви введете exitабо натисніть Ctrl+, Dвесь фоновий процес залишиться, оскільки це не надсилає сигнал відключення на Bash.

Ви можете змусити Bash попередити вас про те, що фонові процеси все ще працюють

shopt -s checkjobs

Існує можливість надіслати SIGHUPвихід, якщо ви знаходитесь в інтерактивній оболонці ( див. Тут ). Але це не працює на моїй машині з Bash 4.2.25. Можливо, це працює для вас

shopt -s huponexit

Отже, коли з'єднання SSH переривається, SIGHUPвідправляється, інакше при чистому виході завдання продовжують працювати? Це пояснює те, що я бачив.
slhck

Так. Сигнал відключення є лише для особливого випадку, коли з'єднання з користувачем перервано.
Рафаель Аренс



@npostavs дякую за інформацію, яку я додав у відповідь.
Рафаель Аренс
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.