LINUX.ORG.RU

Какие сигналы перехватывать обязательно?

 , ,


0

1

Пилю дальше свое поделие.

Теперь задача - перехватывать сигналы, т.к. надо завершится мягко, что-то сохранить, а не падать трупом.

// SIGKILL - Не перехватывается, не игнорится, не обрабатывается, сразу труп
// SIGSTOP - Не перехватывается, не игнорится, не обрабатывается, просто стоп, freeze чтоли?
// SIGTSTP - Это rerise(?) от VSUSP (Ctrl+Z) может быть блокирован, перехвачен, игнорирован
// SIGCONT - Продолжить после стопа, но нет смысла вешать обработчик

// SIGTERM - Может быть блокирован, перехвачен, игнорирован
// SIGINT  - Это Ctrl+C
// SIGQUIT - Ctrl+\ какой-то дамп, я так понял отладочный коредамп

// SIGHUP  - Отвалился терминал? а как потом вернуться в терминал если он отвалился?

// SIGTTOU - Попытка писать в терминал из фона

// SIGPIPE - Брокнутые FIFO или отвалился сокет
// SIGLOST - Потеряно соединение с сервером(?) с любым ли?

// SIGXCPU - Превышен лимит процессорного времени
// SIGXFSZ - Превышен лимит величины размера файла (если к файлу то м.б. ограничение для fat32, а как насчет дисковой квоты?)

// SIGINFO - Кагдила

Какие еще сигналы надо учесть?

★★★★★

Последнее исправление: deep-purple (всего исправлений: 4)

Ответ на: комментарий от niemand

Глянь на первый пост, я дописал еще ))

SIGTERM и SIGHUP

Как видишь - этого мало, кроме сигтерма есть еще несколько, и если ты будешь ловить только сигтерм, то профукаешь остальные.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от E

SIGTTIN забыл

Не забыл, предполагается что на ввод ничего не будет слушаться.

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от deep-purple

Можешь взять пример из гугля.

http://www.4pmp.com/2009/12/a-simple-daemon-in-c/

Обработчики там только на 3 сигналах: 2 мной названных и SIGINT. Кое-что там ещё заблокированно (это тебе решать)

Ты можешь обрабатовать и больше (хоть SIGILL или SIGSEGV), но обычно этих 3 хватает (всё зависит от того, что делает твоя программа)

niemand
()

SIGINT, SIGTERM, SIGPIPE, желательно SIGHUP.

mashina ★★★★★
()

Отвалился терминал? а как потом вернуться в терминал если он отвалился?

Демон обычно сам отключается от терминала.

AptGet ★★★
()
Ответ на: комментарий от AptGet

Это если демон. А если ты зашел по ssh, запустил прилагу, и ssh отвалился на твоей стороне?

А кстати, если:

$ ./prog
$ Ctrl+Z
$ bg
Как отловить в прилаге что её в фон кинули? Через этсамый SIGTTOU?

deep-purple ★★★★★
() автор топика

SIGINT/SIGTERM обязательно, остальное по вкусу.

post-factum ★★★★★
()

Лет 15 назад забил болт на весь этот зоопарк с сигналами, терминалами и другими std(in/out/err) и демонизациями. Пишу все сервера как обыкновенное консольное приложение. Перехватываю только SIGHUP (по нему переоткрываю логи для ротейтов/перечитываю конфиги) и SIGINT по нему корректно завершаюсь. Проблем никогда небыло (главное ввод вывод делать так чтоб всяких sigpipe не возникало) - зато процесс отладки / управления упростился значительно (в любой момент запустил в консоле, виден весь stdout и stderr Ctrl+C - завершился). При переносе в продакшен деманизирую приложение по средством шела прямо из стартап скрипта - в нем же стоит и вачдог на баше (который просто делает waitpid и смотрит по какой причине сервер завершился - если что респавнит и шлет почту).

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

PS. возможно на некоторых *bsd/unix системах могут быть проблемы, я в основном работаю с linux. Пару раз запускал свой софт на FreeBSD, Solaris, Open Solaris, AIX - там в принципе все тоже работало нормально, только приходилось немного править стартап/ватчдог скрипты.

PS.PS Подбешивают демоны которых нельзя запустить в фореграунде (по умолчанию демонизируются и нету ключика аля --foregraund). Если вдруг сломался и не запускается/не работает при этом в логах тишина - то ни подебажить нормально, ни stdin/stderr и если нужно на вачдога посадить - то тоже приходится костыли делать.

zaz ★★★★
()
Ответ на: комментарий от zaz

Ды, я вот хочу вообще шоп сам не умел в демона. Если надо будет, то а-ля 1>> /dev/null 2>> /dev/null &

Хз насколько это нормально..

Но тут вопрос что если он в бг попадет при обычном запуске, то будет продолжать гадить в кансоль свои stdout/stderr мессаги. Как в ём определять что его отправили в бг (не суспенд) (чтоб перестал гадить) и как потом понять что подняли в фг (чтоб продолжил)?

deep-purple ★★★★★
() автор топика
Ответ на: комментарий от deep-purple

Если честно никогда таким не заморачивался. Но могу предположить что это может быть зависимо от конкретного шела (поскольку для ОС нет такого понятия как фореграунд и бекграунд, это больше шел всем этим заведует). Также могу предположить что смотреть нужно в сторону терминальных груп (tcgetpgrp) - шел должен держать фореграунд и бекграунд процессы в различных терминальных группах (тоесть bg/fg должны переводить процесс с одной группы в другую). Насщет сигналов не уверен но я бы посмотрел в сторону SIGTTIN/SIGTTOU

zaz ★★★★
()
Ответ на: комментарий от deep-purple

Как в ём определять что его отправили в бг

не нужно так делать. Если нужно отправить в bg, и чтоб не срал, то перенаправь вывод и отправь в bg. Это не задача самого приложения.

К тому же, удобно отправлять в bg, а сообщения перенаправить в лог-файл.

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

SIGINT/SIGTERM достаточно.

emulek
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.