Я просто не понимаю, как работает определение работы rc Upstart в Natty 11.04. Чтобы проиллюстрировать эту проблему, вот определение (пустые строки и комментарии не учтены):
start on runlevel [0123456]
stop on runlevel [!$RUNLEVEL]
export RUNLEVEL
export PREVLEVEL
console output
env INIT_VERBOSE
task
exec /etc/init.d/rc $RUNLEVEL
Предположим, что мы в настоящее время находимся на уровне выполнения 2, и задание rc прекращено (это как раз ситуация после загрузка моего бокса и вход в систему через SSH). Предположим теперь, что система переключается на уровень запуска 3, например, из-за команды типа «telinit 3», заданной пользователем root. Что произойдет с работой rc?
Очевидно, что задание rc будет запущено, так как оно в настоящий момент остановлено, а уровень запуска 3 соответствует совпадающим событиям запуска. Но отныне мне все непонятно: согласно руководству $ RUNLEVEL оценивает новый уровень запуска при запуске задания (это означает, что в нашем примере 3).
Поэтому следующая строфа «stop» на runlevel [! $ RUNLEVEL] "означает" stop on runlevel [! 3] "; это означает, что у нас есть первая строфа, которая вызовет работу, но вторая строфа никогда не прекратит работу и кажется бесполезной.
Поскольку я знаю, что люди Ubuntu / Upstart не будут делать бесполезные вещи , Я должен сильно что-то недопонимать. Я был бы благодарен за любое объяснение.
. Пытаясь понять это, мне дошел еще один вопрос. Если бы у меня возникли противоречивые триггеры запуска и остановки, например
start on foo
stop on foo
, что произойдет? Клянусь, я никогда этого не сделаю, но мне все же очень интересно, как Upstart справляется с этим на теоретическом уровне.
Большое спасибо!
Редактирование вопроса как реакция на первый ответ гейкозавра:
Я вижу параллелизм, но это не так просто (по крайней мере, не для меня).
Предположим, что работа в настоящее время все еще работает, и появляется новое событие уровня запуска (конечно, новый уровень выполнения отличается от текущего). Затем должно произойти следующее:
1) Задача - это один экземпляр. Это означает, что «start on ...» не будет запущен, поскольку работа в данный момент запущена; $ RUNLEVEL не тронут.
2) «stop on ...» будет запущен, так как новый уровень выполнения отличается от $ RUNLEVEL, поэтому задание будет прервано.
3 ) Теперь работа остановлена и ждет. Я не вижу, как он перезапускается с новым уровнем выполнения. AFAIK, initctl испускает события только один раз, поэтому «начать с ...» не будет запущен, и новый уровень выполнения не будет введен.
Я знаю, что я все еще что-то недопонимаю, и я благодарен для объяснений.
Большое спасибо!
Вы видели мой ответ на Sense of & quot; stop on ... & quot; строфа, когда задача - задача? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.
Однако я не знаю второй части.
На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:
http://upstart.ubuntu.com/cookbook/#ordering-of-stop-start-operations http://upstart.ubuntu.com/cookbook/#job-statesПорядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. Хотя linux является многопроцессорным, механизм событий upstart не является.
Итак, команда уровня запуска, которая испускает событие «runlevel», принимается двигателем состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокироваться до тех пор, пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала, и запускается новое задание rc.
Это фактически документировано в исходном исходном коде:
/* We stop first so that if an event is listed both as a
* stop and start event, it causes an active running process
* to be killed, the stop script then the start script to be
* run. In any other state, it has no special effect.
*
* (The other way around would be just strange, it'd cause
* a process's start and stop scripts to be run without the
* actual process).
*/
Это, вероятно, принадлежит к upstart cookbook, поэтому я открыл там ошибку списка пожеланий:
Вы видели мой ответ на Sense of & quot; stop on ... & quot; строфа, когда задача - задача? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.
Однако я не знаю второй части.
На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:
http://upstart.ubuntu.com/cookbook/#ordering-of-stop-start-operations http://upstart.ubuntu.com/cookbook/#job-statesПорядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. Хотя linux является многопроцессорным, механизм событий upstart не является.
Итак, команда уровня запуска, которая испускает событие «runlevel», принимается двигателем состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокироваться до тех пор, пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала, и запускается новое задание rc.
Это фактически документировано в исходном исходном коде:
/* We stop first so that if an event is listed both as a
* stop and start event, it causes an active running process
* to be killed, the stop script then the start script to be
* run. In any other state, it has no special effect.
*
* (The other way around would be just strange, it'd cause
* a process's start and stop scripts to be run without the
* actual process).
*/
Это, вероятно, принадлежит к upstart cookbook, поэтому я открыл там ошибку списка пожеланий:
Вы видели мой ответ на Sense of & quot; stop on ... & quot; строфа, когда задача - задача? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.
Однако я не знаю второй части.
На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:
http://upstart.ubuntu.com/cookbook/#ordering-of-stop-start-operations http://upstart.ubuntu.com/cookbook/#job-statesПорядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. Хотя linux является многопроцессорным, механизм событий upstart не является.
Итак, команда уровня запуска, которая испускает событие «runlevel», принимается двигателем состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокироваться до тех пор, пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала, и запускается новое задание rc.
Это фактически документировано в исходном исходном коде:
/* We stop first so that if an event is listed both as a
* stop and start event, it causes an active running process
* to be killed, the stop script then the start script to be
* run. In any other state, it has no special effect.
*
* (The other way around would be just strange, it'd cause
* a process's start and stop scripts to be run without the
* actual process).
*/
Это, вероятно, принадлежит к upstart cookbook, поэтому я открыл там ошибку списка пожеланий:
Вы видели мой ответ на Sense of & quot; stop on ... & quot; строфа, когда задача - задача? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.
Однако я не знаю второй части.
На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:
http://upstart.ubuntu.com/cookbook/#ordering-of-stop-start-operations http://upstart.ubuntu.com/cookbook/#job-statesПорядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. Хотя linux является многопроцессорным, механизм событий upstart не является.
Итак, команда уровня запуска, которая испускает событие «runlevel», принимается двигателем состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокироваться до тех пор, пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала, и запускается новое задание rc.
Это фактически документировано в исходном исходном коде:
/* We stop first so that if an event is listed both as a
* stop and start event, it causes an active running process
* to be killed, the stop script then the start script to be
* run. In any other state, it has no special effect.
*
* (The other way around would be just strange, it'd cause
* a process's start and stop scripts to be run without the
* actual process).
*/
Это, вероятно, принадлежит к upstart cookbook, поэтому я открыл там ошибку списка пожеланий:
Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. В то время как linux является многопроцессором, механизмом событий upstart нет.
Итак, команда уровня запуска, которая испускает событие «уровень запуска», принимается механизмом состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокировать , пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала и запускается новое задание rc.
Это фактически задокументировано в исходном исходном коде:
/ * Мы останавливаем сначала так что, если событие указано как событие * stop и start, оно приводит к тому, что активный запущенный процесс * должен быть убит, сценарий останова, а затем запускается сценарий запуска. В любом другом состоянии это не имеет особого эффекта. * * (Другим способом было бы просто странно, это заставило бы * запускать и останавливать сценарии процесса без реального процесса). * /
Это, вероятно, принадлежит к кулинарной книге , поэтому я открыл там ошибку списка желаний:
На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:
Вы видели мой ответ на Sense of & quot; stop on ... & quot; stanza, когда задание является задачей ? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.
Однако я не знаю второй части.
Вы видели мой ответ на Sense of & quot; stop on ... & quot; stanza, когда задание является задачей ? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.
Однако я не знаю второй части.
На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:
Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. В то время как linux является многопроцессором, механизмом событий upstart нет.
Итак, команда уровня запуска, которая испускает событие «уровень запуска», принимается механизмом состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокировать , пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала и запускается новое задание rc.
Это фактически задокументировано в исходном исходном коде:
/ * Мы останавливаем сначала так что, если событие указано как событие * stop и start, оно приводит к тому, что активный запущенный процесс * должен быть убит, сценарий останова, а затем запускается сценарий запуска. В любом другом состоянии это не имеет особого эффекта. * * (Другим способом было бы просто странно, это заставило бы * запускать и останавливать сценарии процесса без реального процесса). * /
Это, вероятно, принадлежит к кулинарной книге , поэтому я открыл там ошибку списка желаний:
Вы видели мой ответ на Sense of & quot; stop on ... & quot; stanza, когда задание является задачей ? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.
Однако я не знаю второй части.
На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:
Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. В то время как linux является многопроцессором, механизмом событий upstart нет.
Итак, команда уровня запуска, которая испускает событие «уровень запуска», принимается механизмом состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокировать , пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала и запускается новое задание rc.
Это фактически задокументировано в исходном исходном коде:
/ * Мы останавливаем сначала так что, если событие указано как событие * stop и start, оно приводит к тому, что активный запущенный процесс * должен быть убит, сценарий останова, а затем запускается сценарий запуска. В любом другом состоянии это не имеет особого эффекта. * * (Другим способом было бы просто странно, это заставило бы * запускать и останавливать сценарии процесса без реального процесса). * /
Это, вероятно, принадлежит к кулинарной книге , поэтому я открыл там ошибку списка желаний:
Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. В то время как linux является многопроцессором, механизмом событий upstart нет.
Итак, команда уровня запуска, которая испускает событие «уровень запуска», принимается механизмом состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокировать , пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала и запускается новое задание rc.
Это фактически задокументировано в исходном исходном коде:
/ * Мы останавливаем сначала так что, если событие указано как событие * stop и start, оно приводит к тому, что активный запущенный процесс * должен быть убит, сценарий останова, а затем запускается сценарий запуска. В любом другом состоянии это не имеет особого эффекта. * * (Другим способом было бы просто странно, это заставило бы * запускать и останавливать сценарии процесса без реального процесса). * /
Это, вероятно, принадлежит к кулинарной книге , поэтому я открыл там ошибку списка желаний:
Вы видели мой ответ на Sense of & quot; stop on ... & quot; stanza, когда задание является задачей ? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.
Однако я не знаю второй части.
запусков на
/ останавливаться на
строфах или разделах, разделенных запятыми в одной строфе. Это будет срабатывать дважды: один раз в запустите
, чтобы запустить новый экземпляр, а затем для остановки на
, чтобы убить старый. Если вы внимательно прочитали детали в init (5)
и upstart (8)
, вы заметите, что upstart
знает, что соответствует остановитесь на
на существующее задание, потому что $ RUNLEVEL
- export
ed до upstart
в качестве параметра задания.
– geekosaur
17 March 2011 в 03:26
$ RUNLEVEL
- export
ed, upstart
запоминает $ RUNLEVEL
, связанный с каждым запуском задания rc
. Когда останавливается на
, функция upstart
ищет экземпляры rc
, у которых есть $ RUNLEVEL
, который соответствует шаблону [! $ RUNLEVEL]
и останавливает только те. Новый экземпляр явно не соответствует [! $ RUNLEVEL]
, потому что он является i> $ RUNLEVEL
, поэтому остается в силе. (Er, все еще немного запутанный). Шаблон, который он использует для сопоставления, представляет собой текущий $ RUNLEVEL
, сопоставляемый с сохраненным $ RUNLEVEL
для каждого задания.)
– geekosaur
17 March 2011 в 03:34
export
значениями переменных; другой имеет то же самое, но имеет разные имена экземпляра
, чтобы различать их. Таким образом, может быть только один экземпляр «полного имени задания». в то время, и export
variables и instance
s являются двумя способами изменения компонентов этих «полностью квалифицированных». имена. Тем не менее, возможно, что upstart
достаточно умен, чтобы сначала запустить остановку на
, так что когда начнется с
t - любое другое задание rc
.
– geekosaur
17 March 2011 в 03:47
На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:
Теперь мы четко описали (надеюсь), как работает «rc» в Ubuntu в Cookbook Upstart. У него даже есть свой раздел:
http://upstart.ubuntu.com/cookbook/#the-rc-job
Однако для полный контекст, я предлагаю вам прочитать здесь:
http://upstart.ubuntu.com/cookbook/#really-understanding-start-on-and-stop-on