Как работает работа rc / порядок (противоречит) & ldquo; start on & hellip; & rdquo; и & ldquo; остановить на & hellip; & rdquo; строфы

Я просто не понимаю, как работает определение работы 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 испускает события только один раз, поэтому «начать с ...» не будет запущен, и новый уровень выполнения не будет введен.

Я знаю, что я все еще что-то недопонимаю, и я благодарен для объяснений.

Большое спасибо!

3
задан 18 March 2011 в 03:38

25 ответов

Вы видели мой ответ на Sense of & quot; stop on ... & quot; строфа, когда задача - задача? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.

Однако я не знаю второй части.

1
ответ дан 25 July 2018 в 22:20
  • 1
    Я написал второй вопрос одновременно с тем, как вы написали ответ на первый ... Я вижу параллелизм, но это не так просто: остановка строфы срабатывает только в том случае, если уровень запуска не равен $ RUNLEVEL. Это означает, что в задании всегда есть тот же самый $ RUNLEVEL. Таким образом, я вижу, как задание остановлено / прервано, но не как его перезапустить с новым уровнем выполнения. AFAIK, initctl испускает события ровно один раз. Событие переключения уровня запуска будет потребляться для остановки старого задания, и новое задание не будет запущено, потому что событие больше не будет выбрано? – Binarus 17 March 2011 в 03:19
  • 2
    Он испускается только один раз, но несколько заданий могут ожидать его излучения, и одна и та же работа может срабатывать несколько раз с помощью нескольких start on / stop on строф или разделенных запятыми статей в одной строфе. Это будет срабатывать дважды: один раз в start on, чтобы запустить новый экземпляр, затем снова для stop on, чтобы убить старый. Если вы внимательно прочитали детали в init(5) и upstart(8), вы заметите, что upstart знает, что соответствует stop on для существующего задания, потому что $RUNLEVEL - export ed до upstart в качестве задания параметр. – geekosaur 17 March 2011 в 03:26
  • 3
    Чтобы пояснить немного больше (было немного близко к пределу длины комментария), потому что $RUNLEVEL является export ed, upstart запоминает $RUNLEVEL, связанный с каждым запуском задания rc. Когда запускается stop on, upstart ищет экземпляры rc, у которых есть $RUNLEVEL, который соответствует шаблону [!$RUNLEVEL] и останавливает только те. Новый экземпляр явно не соответствует [!$RUNLEVEL], потому что он равен $RUNLEVEL, поэтому он остается один. (Er, все еще немного запутанный. Образец, который он использует для сопоставления, представляет собой текущий $RUNLEVEL, который сопоставляется с сохраненным $RUNLEVEL для каждого задания.) – geekosaur 17 March 2011 в 03:34
  • 4
    Hmmm, больше параллельной публикации :-) Хорошо, тогда я не мог найти строфу экземпляра в определении задания, поэтому я думал, что работа rc - это единственный экземпляр. Но согласно тому, что вы говорите, rc должен быть мультиэкземпляром. Теперь я волнуюсь ... – Binarus 17 March 2011 в 03:40
  • 5
    Как я понимаю, существует два типа «экземпляров». У одного есть одно и то же имя работы, но разные значения переменной export; другой имеет их одно и то же, но имеет разные имена instance, чтобы отличить их. Таким образом, может быть только один экземпляр «полного имени задания». в то время, и export переменные и instance s являются двумя способами изменения компонентов этих "полностью квалифицированных" имена. Тем не менее, возможно, что upstart достаточно умен, чтобы сначала запустить stop on, чтобы при оценке start on не было никаких других rc заданий. – geekosaur 17 March 2011 в 03:47

На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:

http://upstart.ubuntu.com/cookbook/#ordering-of-stop-start-operations http://upstart.ubuntu.com/cookbook/#job-states
3
ответ дан 25 July 2018 в 22:20

Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. Хотя 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, поэтому я открыл там ошибку списка пожеланий:

upstart cookbook

3
ответ дан 25 July 2018 в 22:20

Вы видели мой ответ на Sense of & quot; stop on ... & quot; строфа, когда задача - задача? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.

Однако я не знаю второй части.

1
ответ дан 31 July 2018 в 13:13
  • 1
    Я написал второй вопрос одновременно с тем, как вы написали ответ на первый ... Я вижу параллелизм, но это не так просто: остановка строфы срабатывает только в том случае, если уровень запуска не равен $ RUNLEVEL. Это означает, что в задании всегда есть тот же самый $ RUNLEVEL. Таким образом, я вижу, как задание остановлено / прервано, но не как его перезапустить с новым уровнем выполнения. AFAIK, initctl испускает события ровно один раз. Событие переключения уровня запуска будет потребляться для остановки старого задания, и новое задание не будет запущено, потому что событие больше не будет выбрано? – Binarus 17 March 2011 в 03:19
  • 2
    Он испускается только один раз, но несколько заданий могут ожидать его излучения, и одна и та же работа может срабатывать несколько раз с помощью нескольких start on / stop on строф или разделенных запятыми статей в одной строфе. Это будет срабатывать дважды: один раз в start on, чтобы запустить новый экземпляр, затем снова для stop on, чтобы убить старый. Если вы внимательно прочитали детали в init(5) и upstart(8), вы заметите, что upstart знает, что соответствует stop on для существующего задания, потому что $RUNLEVEL - export ed до upstart в качестве задания параметр. – geekosaur 17 March 2011 в 03:26
  • 3
    Чтобы пояснить немного больше (было немного близко к пределу длины комментария), потому что $RUNLEVEL является export ed, upstart запоминает $RUNLEVEL, связанный с каждым запуском задания rc. Когда запускается stop on, upstart ищет экземпляры rc, у которых есть $RUNLEVEL, который соответствует шаблону [!$RUNLEVEL] и останавливает только те. Новый экземпляр явно не соответствует [!$RUNLEVEL], потому что он равен $RUNLEVEL, поэтому он остается один. (Er, все еще немного запутанный. Образец, который он использует для сопоставления, представляет собой текущий $RUNLEVEL, который сопоставляется с сохраненным $RUNLEVEL для каждого задания.) – geekosaur 17 March 2011 в 03:34
  • 4
    Hmmm, больше параллельной публикации :-) Хорошо, тогда я не мог найти строфу экземпляра в определении задания, поэтому я думал, что работа rc - это единственный экземпляр. Но согласно тому, что вы говорите, rc должен быть мультиэкземпляром. Теперь я волнуюсь ... – Binarus 17 March 2011 в 03:40
  • 5
    Как я понимаю, существует два типа «экземпляров». У одного есть одно и то же имя работы, но разные значения переменной export; другой имеет их одно и то же, но имеет разные имена instance, чтобы отличить их. Таким образом, может быть только один экземпляр «полного имени задания». в то время, и export переменные и instance s являются двумя способами изменения компонентов этих "полностью квалифицированных" имена. Тем не менее, возможно, что upstart достаточно умен, чтобы сначала запустить stop on, чтобы при оценке start on не было никаких других rc заданий. – geekosaur 17 March 2011 в 03:47

На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:

http://upstart.ubuntu.com/cookbook/#ordering-of-stop-start-operations http://upstart.ubuntu.com/cookbook/#job-states
3
ответ дан 31 July 2018 в 13:13

Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. Хотя 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, поэтому я открыл там ошибку списка пожеланий:

upstart cookbook

3
ответ дан 31 July 2018 в 13:13

Вы видели мой ответ на Sense of & quot; stop on ... & quot; строфа, когда задача - задача? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.

Однако я не знаю второй части.

1
ответ дан 2 August 2018 в 03:48
  • 1
    Я написал второй вопрос одновременно с тем, как вы написали ответ на первый ... Я вижу параллелизм, но это не так просто: остановка строфы срабатывает только в том случае, если уровень запуска не равен $ RUNLEVEL. Это означает, что в задании всегда есть тот же самый $ RUNLEVEL. Таким образом, я вижу, как задание остановлено / прервано, но не как его перезапустить с новым уровнем выполнения. AFAIK, initctl испускает события ровно один раз. Событие переключения уровня запуска будет потребляться для остановки старого задания, и новое задание не будет запущено, потому что событие больше не будет выбрано? – Binarus 17 March 2011 в 03:19
  • 2
    Он испускается только один раз, но несколько заданий могут ожидать его излучения, и одна и та же работа может срабатывать несколько раз с помощью нескольких start on / stop on строф или разделенных запятыми статей в одной строфе. Это будет срабатывать дважды: один раз в start on, чтобы запустить новый экземпляр, затем снова для stop on, чтобы убить старый. Если вы внимательно прочитали детали в init(5) и upstart(8), вы заметите, что upstart знает, что соответствует stop on для существующего задания, потому что $RUNLEVEL - export ed до upstart в качестве задания параметр. – geekosaur 17 March 2011 в 03:26
  • 3
    Чтобы пояснить немного больше (было немного близко к пределу длины комментария), потому что $RUNLEVEL является export ed, upstart запоминает $RUNLEVEL, связанный с каждым запуском задания rc. Когда запускается stop on, upstart ищет экземпляры rc, у которых есть $RUNLEVEL, который соответствует шаблону [!$RUNLEVEL] и останавливает только те. Новый экземпляр явно не соответствует [!$RUNLEVEL], потому что он равен $RUNLEVEL, поэтому он остается один. (Er, все еще немного запутанный. Образец, который он использует для сопоставления, представляет собой текущий $RUNLEVEL, который сопоставляется с сохраненным $RUNLEVEL для каждого задания.) – geekosaur 17 March 2011 в 03:34
  • 4
    Hmmm, больше параллельной публикации :-) Хорошо, тогда я не мог найти строфу экземпляра в определении задания, поэтому я думал, что работа rc - это единственный экземпляр. Но согласно тому, что вы говорите, rc должен быть мультиэкземпляром. Теперь я волнуюсь ... – Binarus 17 March 2011 в 03:40
  • 5
    Как я понимаю, существует два типа «экземпляров». У одного есть одно и то же имя работы, но разные значения переменной export; другой имеет их одно и то же, но имеет разные имена instance, чтобы отличить их. Таким образом, может быть только один экземпляр «полного имени задания». в то время, и export переменные и instance s являются двумя способами изменения компонентов этих "полностью квалифицированных" имена. Тем не менее, возможно, что upstart достаточно умен, чтобы сначала запустить stop on, чтобы при оценке start on не было никаких других rc заданий. – geekosaur 17 March 2011 в 03:47

На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:

http://upstart.ubuntu.com/cookbook/#ordering-of-stop-start-operations http://upstart.ubuntu.com/cookbook/#job-states
3
ответ дан 2 August 2018 в 03:48

Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. Хотя 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, поэтому я открыл там ошибку списка пожеланий:

upstart cookbook

3
ответ дан 2 August 2018 в 03:48

Вы видели мой ответ на Sense of & quot; stop on ... & quot; строфа, когда задача - задача? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.

Однако я не знаю второй части.

1
ответ дан 4 August 2018 в 19:52
  • 1
    Я написал второй вопрос одновременно с тем, как вы написали ответ на первый ... Я вижу параллелизм, но это не так просто: остановка строфы срабатывает только в том случае, если уровень запуска не равен $ RUNLEVEL. Это означает, что в задании всегда есть тот же самый $ RUNLEVEL. Таким образом, я вижу, как задание остановлено / прервано, но не как его перезапустить с новым уровнем выполнения. AFAIK, initctl испускает события ровно один раз. Событие переключения уровня запуска будет потребляться для остановки старого задания, и новое задание не будет запущено, потому что событие больше не будет выбрано? – Binarus 17 March 2011 в 03:19
  • 2
    Он испускается только один раз, но несколько заданий могут ожидать его излучения, и одна и та же работа может срабатывать несколько раз с помощью нескольких start on / stop on строф или разделенных запятыми статей в одной строфе. Это будет срабатывать дважды: один раз в start on, чтобы запустить новый экземпляр, затем снова для stop on, чтобы убить старый. Если вы внимательно прочитали детали в init(5) и upstart(8), вы заметите, что upstart знает, что соответствует stop on для существующего задания, потому что $RUNLEVEL - export ed до upstart в качестве задания параметр. – geekosaur 17 March 2011 в 03:26
  • 3
    Чтобы пояснить немного больше (было немного близко к пределу длины комментария), потому что $RUNLEVEL является export ed, upstart запоминает $RUNLEVEL, связанный с каждым запуском задания rc. Когда запускается stop on, upstart ищет экземпляры rc, у которых есть $RUNLEVEL, который соответствует шаблону [!$RUNLEVEL] и останавливает только те. Новый экземпляр явно не соответствует [!$RUNLEVEL], потому что он равен $RUNLEVEL, поэтому он остается один. (Er, все еще немного запутанный. Образец, который он использует для сопоставления, представляет собой текущий $RUNLEVEL, который сопоставляется с сохраненным $RUNLEVEL для каждого задания.) – geekosaur 17 March 2011 в 03:34
  • 4
    Hmmm, больше параллельной публикации :-) Хорошо, тогда я не мог найти строфу экземпляра в определении задания, поэтому я думал, что работа rc - это единственный экземпляр. Но согласно тому, что вы говорите, rc должен быть мультиэкземпляром. Теперь я волнуюсь ... – Binarus 17 March 2011 в 03:40
  • 5
    Как я понимаю, существует два типа «экземпляров». У одного есть одно и то же имя работы, но разные значения переменной export; другой имеет их одно и то же, но имеет разные имена instance, чтобы отличить их. Таким образом, может быть только один экземпляр «полного имени задания». в то время, и export переменные и instance s являются двумя способами изменения компонентов этих "полностью квалифицированных" имена. Тем не менее, возможно, что upstart достаточно умен, чтобы сначала запустить stop on, чтобы при оценке start on не было никаких других rc заданий. – geekosaur 17 March 2011 в 03:47

На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:

http://upstart.ubuntu.com/cookbook/#ordering-of-stop-start-operations http://upstart.ubuntu.com/cookbook/#job-states
3
ответ дан 4 August 2018 в 19:52

Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. Хотя 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, поэтому я открыл там ошибку списка пожеланий:

upstart cookbook

3
ответ дан 4 August 2018 в 19:52

Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. В то время как linux является многопроцессором, механизмом событий upstart нет.

Итак, команда уровня запуска, которая испускает событие «уровень запуска», принимается механизмом состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокировать , пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала и запускается новое задание rc.

Это фактически задокументировано в исходном исходном коде:

  / * Мы останавливаем сначала  так что, если событие указано как событие * stop и start, оно приводит к тому, что активный запущенный процесс * должен быть убит, сценарий останова, а затем запускается сценарий запуска.  В любом другом состоянии это не имеет особого эффекта.  * * (Другим способом было бы просто странно, это заставило бы * запускать и останавливать сценарии процесса без реального процесса).  * /  

Это, вероятно, принадлежит к кулинарной книге , поэтому я открыл там ошибку списка желаний:

https://bugs.launchpad.net/upstart-cookbook/+bug/745096

3
ответ дан 6 August 2018 в 03:55

На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:

3
ответ дан 6 August 2018 в 03:55

Вы видели мой ответ на Sense of & quot; stop on ... & quot; stanza, когда задание является задачей ? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.

Однако я не знаю второй части.

1
ответ дан 6 August 2018 в 03:55

Вы видели мой ответ на Sense of & quot; stop on ... & quot; stanza, когда задание является задачей ? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.

Однако я не знаю второй части.

1
ответ дан 7 August 2018 в 21:52

На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:

3
ответ дан 7 August 2018 в 21:52

Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. В то время как linux является многопроцессором, механизмом событий upstart нет.

Итак, команда уровня запуска, которая испускает событие «уровень запуска», принимается механизмом состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокировать , пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала и запускается новое задание rc.

Это фактически задокументировано в исходном исходном коде:

  / * Мы останавливаем сначала  так что, если событие указано как событие * stop и start, оно приводит к тому, что активный запущенный процесс * должен быть убит, сценарий останова, а затем запускается сценарий запуска.  В любом другом состоянии это не имеет особого эффекта.  * * (Другим способом было бы просто странно, это заставило бы * запускать и останавливать сценарии процесса без реального процесса).  * /  

Это, вероятно, принадлежит к кулинарной книге , поэтому я открыл там ошибку списка желаний:

https://bugs.launchpad.net/upstart-cookbook/+bug/745096

3
ответ дан 7 August 2018 в 21:52

Вы видели мой ответ на Sense of & quot; stop on ... & quot; stanza, когда задание является задачей ? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.

Однако я не знаю второй части.

1
ответ дан 10 August 2018 в 10:07

На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:

3
ответ дан 10 August 2018 в 10:07

Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. В то время как linux является многопроцессором, механизмом событий upstart нет.

Итак, команда уровня запуска, которая испускает событие «уровень запуска», принимается механизмом состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокировать , пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала и запускается новое задание rc.

Это фактически задокументировано в исходном исходном коде:

  / * Мы останавливаем сначала  так что, если событие указано как событие * stop и start, оно приводит к тому, что активный запущенный процесс * должен быть убит, сценарий останова, а затем запускается сценарий запуска.  В любом другом состоянии это не имеет особого эффекта.  * * (Другим способом было бы просто странно, это заставило бы * запускать и останавливать сценарии процесса без реального процесса).  * /  

Это, вероятно, принадлежит к кулинарной книге , поэтому я открыл там ошибку списка желаний:

https://bugs.launchpad.net/upstart-cookbook/+bug/745096

3
ответ дан 10 August 2018 в 10:07

Порядок операций очень тщательно поддерживается при выскочке при обработке событий. Остатки, вызванные событием, всегда выполняются перед запуском. В то время как linux является многопроцессором, механизмом событий upstart нет.

Итак, команда уровня запуска, которая испускает событие «уровень запуска», принимается механизмом состояния выскочки, а затем обрабатывается, сначала делая все переходы от начала до конца. Это будет блокировать , пока первый rc не будет убит и не погибнет. Затем выполняются переходы от остановки до начала и запускается новое задание rc.

Это фактически задокументировано в исходном исходном коде:

  / * Мы останавливаем сначала  так что, если событие указано как событие * stop и start, оно приводит к тому, что активный запущенный процесс * должен быть убит, сценарий останова, а затем запускается сценарий запуска.  В любом другом состоянии это не имеет особого эффекта.  * * (Другим способом было бы просто странно, это заставило бы * запускать и останавливать сценарии процесса без реального процесса).  * /  

Это, вероятно, принадлежит к кулинарной книге , поэтому я открыл там ошибку списка желаний:

https://bugs.launchpad.net/upstart-cookbook/+bug/745096

3
ответ дан 13 August 2018 в 16:27

Вы видели мой ответ на Sense of & quot; stop on ... & quot; stanza, когда задание является задачей ? Тот же ответ относится к первой части вашего вопроса, он используется для отмены запуска уровня запуска, если пользователь переключится на другой уровень выполнения до его завершения.

Однако я не знаю второй части.

1
ответ дан 13 August 2018 в 16:27
  • 1
    Я написал второй вопрос одновременно с тем, как вы написали ответ на первый ... Я вижу параллелизм, но это не так просто: остановка строфы срабатывает только в том случае, если уровень запуска не равен $ RUNLEVEL. Это означает, что в задании всегда есть тот же самый $ RUNLEVEL. Таким образом, я могу видеть, как задание остановлено / прервано, но не как его перезапустить с помощью уровня new . AFAIK, initctl испускает события ровно один раз. Событие переключения уровня запуска будет потребляться для остановки старого задания, и новое задание не будет запущено, потому что событие больше не будет выбрано? – Binarus 17 March 2011 в 03:19
  • 2
    Он выдается только один раз, но несколько заданий могут ожидать его выброса, и одно и то же задание может запускаться несколько раз с помощью нескольких запусков на / останавливаться на строфах или разделах, разделенных запятыми в одной строфе. Это будет срабатывать дважды: один раз в запустите , чтобы запустить новый экземпляр, а затем для остановки на , чтобы убить старый. Если вы внимательно прочитали детали в init (5) и upstart (8) , вы заметите, что upstart знает, что соответствует остановитесь на на существующее задание, потому что $ RUNLEVEL - export ed до upstart в качестве параметра задания. – geekosaur 17 March 2011 в 03:26
  • 3
    Чтобы уточнить немного (было немного ближе к пределу длины комментария), потому что $ RUNLEVEL - export ed, upstart запоминает $ RUNLEVEL , связанный с каждым запуском задания rc . Когда останавливается на , функция upstart ищет экземпляры rc , у которых есть $ RUNLEVEL , который соответствует шаблону [! $ RUNLEVEL] и останавливает только те. Новый экземпляр явно не соответствует [! $ RUNLEVEL] , потому что он является $ RUNLEVEL , поэтому остается в силе. (Er, все еще немного запутанный). Шаблон, который он использует для сопоставления, представляет собой текущий $ RUNLEVEL , сопоставляемый с сохраненным $ RUNLEVEL для каждого задания.) – geekosaur 17 March 2011 в 03:34
  • 4
    Hmmm, больше параллельной публикации :-) Хорошо, тогда я не мог найти строфу экземпляра в определении задания, поэтому я думал, что работа rc - это единственный экземпляр. Но согласно тому, что вы говорите, rc должен быть мультиэкземпляром. Теперь я волнуюсь ... – Binarus 17 March 2011 в 03:40
  • 5
    Как я понимаю, существует два типа «экземпляров». Один имеет то же имя работы, но отличается export значениями переменных; другой имеет то же самое, но имеет разные имена экземпляра , чтобы различать их. Таким образом, может быть только один экземпляр «полного имени задания». в то время, и export variables и instance s являются двумя способами изменения компонентов этих «полностью квалифицированных». имена. Тем не менее, возможно, что upstart достаточно умен, чтобы сначала запустить остановку на , так что когда начнется с t - любое другое задание rc . – geekosaur 17 March 2011 в 03:47

На оставшуюся часть вашего вопроса теперь должны ответить следующие разделы в книге Upstart Cookbook:

3
ответ дан 13 August 2018 в 16:27

Теперь мы четко описали (надеюсь), как работает «rc» в Ubuntu в Cookbook Upstart. У него даже есть свой раздел:

http://upstart.ubuntu.com/cookbook/#the-rc-job

Однако для полный контекст, я предлагаю вам прочитать здесь:

http://upstart.ubuntu.com/cookbook/#really-understanding-start-on-and-stop-on

3
ответ дан 15 August 2018 в 23:11

Другие вопросы по тегам:

Похожие вопросы: