Есть два способа, которые я нашел для решения этой проблемы, ни один из них не идеален:
kill signal
. Если вы установите kill signal QUIT
, а также kill timeout 600
, Upstart пошлет SIGQUIT
процессу, затем подождет 600 секунд перед отправкой SIGKILL
. Если процесс завершится до отправки SIGKILL
, то все в порядке. С этим подходом есть проблемы: (a) он посылает SIGKILL
, а не SIGTERM
после таймаута, что не позволяет рабочему resque красиво закрыться, но это не страшно. (b) Более серьезная проблема, которую я обнаружил, заключается в том, что upstart посылает "сигнал убийства" (в нашем случае SIGQUIT
) всем процессам в сессии, что, вероятно, будет мешать работе дочерних процессов рабочего resque (SIGQUIT
по умолчанию завершается дампом ядра). SIGTERM
), и обрабатывайте все плавные завершения самостоятельно. В этом случае важно установить для Upstart kill timeout
время, достаточное для того, чтобы ваша обёртка могла выполнить плавное завершение работы и либо принудительно прервать его по истечении времени (в этом случае убедитесь, что таймаут немного меньше, чем у Upstart), либо просто полагаться на SIGKILL
Upstart для очистки (что может быть хорошей или не очень идеей в зависимости от ваших требований). Минусы: это довольно сложно сделать правильно, и причина существования Upstart в том, что вам не придется самостоятельно писать менеджер процессов для каждой службы. Если вы не хотите идти ни тем, ни другим путем, существуют другие менеджеры процессов, которые могут реализовать более сложный режим сигналов, чем поддерживаемый Upstart, и их обычно легко реализовать под Upstart для управления только тем процессом, с которым у вас возникла проблема. К сожалению, трудно найти такой менеджер, который работает правильно во всех случаях. Например, я пробовал Bluepill, который отлично выглядит на бумаге, но на момент написания статьи имеет очевидную ошибку, когда если вы пытаетесь использовать сложный режим сигналов с несколькими сигналами и несколькими таймаутами, он просто посылает все сигналы сразу (не обязательно в правильном порядке) и разрушает дочерний процесс.
Если у кого-то есть дополнительная информация, не стесняйтесь добавлять новые ответы, и я могу даже пометить это как "ответ" (вместо моего собственного ответа), если это хорошо.
Estoy usando la siguiente forma:
ttyv0
mi usuario inicia sesión automáticamente. ~/.login
comprueba el tty. Si es ttyv0
se ejecutará startx
. startx
(cierre la sesión xorg )pregunta acerca de detener/reiniciar. Explicaciones:
1. Iniciar sesión automáticamente:en/etc/ttys
:
ttyv0 "/usr/libexec/getty autologin" xterm on secure
y a/etc/gettytab
:
autologin::al=MYUSER
2. & 3. Contenido relevante de~/.login
. Estoy usando tcsh
pero la idea también funciona en sh
:
if ($tty == "ttyv0") then
echo Starting Xorg...
startx
echo "Halt (h) Reboot (r) Nothing (n) ?"
set answer = $<
if ($answer == "h") then
/sbin/shutdown -p now
else if ($answer == "r") then
/sbin/shutdown -r now
endif
endif