Как я могу убедиться, что одно стартовое задание начинается перед другими заданиями Upstart?

Question 1

Альтернативой является использование команды hciconfig. Он четко отобразит интерфейсы, и вы увидите по маркеру «RUNNING» или «DOWN», каков его текущий статус.

Question 2

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 3

Question 4

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 5

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 6

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 7

Question 8

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 9

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

  # service-a  -wait start on (запуск службы-b или запуск службы-c или запуск службы -d) остановка (начальная служба-a или остановленная служба-a) # Мы знаем, что у нас есть более одного задания, которое должно ждать обслуживания,  a и # будут использовать эту службу, поэтому нам нужно создать экземпляр.  экземпляр $ JOB # Необходимо сделать успешное выполнение задания, несмотря на то, что он был убит. normal status 2 task script status service-a |  grep -q "start / running" & amp; & amp; & amp; & amp;  exit 0 start service-a ||  true # Ожидание навсегда - это нормально. upstart убьет это задание, когда # служба - мы пытались начать сверху или начинать или останавливаться во время сна 3600;  делать :;  done end script

То, что это означает на простом английском языке, это: когда сигналы службы b, c или d, которые они хотят запустить, они должны дождаться, пока не будет выполнено обслуживание-a Бег. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения службы-a-wait теперь службы b, c и d могут свободно выполняться и выполняться.

Это будет гарантировать, что служба-a будет запущена и запущена до того, как начнет запускаться любая из ее обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает в первую очередь.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 10

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

  # service-a  -wait start on (запуск службы-b или запуск службы-c или запуск службы -d) остановка (начальная служба-a или остановленная служба-a) # Мы знаем, что у нас есть более одного задания, которое должно ждать обслуживания,  a и # будут использовать эту службу, поэтому нам нужно создать экземпляр.  экземпляр $ JOB # Необходимо сделать успешное выполнение задания, несмотря на то, что он был убит. normal status 2 task script status service-a |  grep -q "start / running" & amp; & amp; & amp; & amp;  exit 0 start service-a ||  true # Ожидание навсегда - это нормально. upstart убьет это задание, когда # служба - мы пытались начать сверху или начинать или останавливаться во время сна 3600;  делать :;  done end script

То, что это означает на простом английском языке, это: когда сигналы службы b, c или d, которые они хотят запустить, они должны дождаться, пока не будет выполнено обслуживание-a Бег. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения службы-a-wait теперь службы b, c и d могут свободно выполняться и выполняться.

Это будет гарантировать, что служба-a будет запущена и запущена до того, как начнет запускаться любая из ее обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает в первую очередь.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 11

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

  # service-a  -wait start on (запуск службы-b или запуск службы-c или запуск службы -d) остановка (начальная служба-a или остановленная служба-a) # Мы знаем, что у нас есть более одного задания, которое должно ждать обслуживания,  a и # будут использовать эту службу, поэтому нам нужно создать экземпляр.  экземпляр $ JOB # Необходимо сделать успешное выполнение задания, несмотря на то, что он был убит. normal status 2 task script status service-a |  grep -q "start / running" & amp; & amp; & amp; & amp;  exit 0 start service-a ||  true # Ожидание навсегда - это нормально. upstart убьет это задание, когда # служба - мы пытались начать сверху или начинать или останавливаться во время сна 3600;  делать :;  done end script

То, что это означает на простом английском языке, это: когда сигналы службы b, c или d, которые они хотят запустить, они должны дождаться, пока не будет выполнено обслуживание-a Бег. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения службы-a-wait теперь службы b, c и d могут свободно выполняться и выполняться.

Это будет гарантировать, что служба-a будет запущена и запущена до того, как начнет запускаться любая из ее обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает в первую очередь.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 12

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

  # service-a  -wait start on (запуск службы-b или запуск службы-c или запуск службы -d) остановка (начальная служба-a или остановленная служба-a) # Мы знаем, что у нас есть более одного задания, которое должно ждать обслуживания,  a и # будут использовать эту службу, поэтому нам нужно создать экземпляр.  экземпляр $ JOB # Необходимо сделать успешное выполнение задания, несмотря на то, что он был убит. normal status 2 task script status service-a |  grep -q "start / running" & amp; & amp; & amp; & amp;  exit 0 start service-a ||  true # Ожидание навсегда - это нормально. upstart убьет это задание, когда # служба - мы пытались начать сверху или начинать или останавливаться во время сна 3600;  делать :;  done end script

То, что это означает на простом английском языке, это: когда сигналы службы b, c или d, которые они хотят запустить, они должны дождаться, пока не будет выполнено обслуживание-a Бег. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения службы-a-wait теперь службы b, c и d могут свободно выполняться и выполняться.

Это обеспечит запуск сервиса-a до того, как начнется запуск любой из его обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает в первую очередь.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Question 13

Question 14

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

Question 15

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

Question 16

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

Question 17

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

Question 18

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

Question 19

Question 20

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d2]

Например, файл конфигурации Upstart /etc/init/centrify.conf мог бы сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого слова в английский язык будет выглядеть следующим образом:

запустите службу Centrify перед либо cron, autofs или nis start (в зависимости от того, что начинается с первого раза).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, как начнется сервис сначала, Centrify запускается до запуска любой из этих служб.

Также обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify начал работать.

Очень элегантный и простой, как только вы привыкли думать таким образом.

Question 21

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d2]

Например, файл конфигурации Upstart /etc/init/centrify.conf мог бы сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого слова в английский язык будет выглядеть следующим образом:

запустите службу Centrify перед либо cron, autofs или nis start (в зависимости от того, что начинается с первого раза).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, как начнется сервис сначала, Centrify запускается до запуска любой из этих служб.

Также обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify начал работать.

Очень элегантный и простой, как только вы привыкли думать таким образом.

Question 22

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d2]

Например, файл конфигурации Upstart /etc/init/centrify.conf мог бы сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого слова в английский язык будет выглядеть следующим образом:

запустите службу Centrify перед либо cron, autofs или nis start (в зависимости от того, что начинается с первого раза).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, как начнется сервис сначала, Centrify запускается до запуска любой из этих служб.

Также обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify начал работать.

Очень элегантный и простой, как только вы привыкли думать таким образом.

Question 23

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d2]

Например, файл конфигурации Upstart /etc/init/centrify.conf мог бы сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого слова в английский язык будет выглядеть следующим образом:

запустите службу Centrify перед либо cron, autofs или nis start (в зависимости от того, что начинается с первого раза).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, как начнется сервис сначала, Centrify запускается до запуска любой из этих служб.

Также обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify начал работать.

Очень элегантный и простой, как только вы привыкли думать таким образом.

Mark Russell · Accepted Answer · 25 May 2018 в 23:29

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Я не понимаю ... что мешает условию гонки между запуском службы A и службой B, продолжающей работать? Я не вижу, как выскочка узнает, что скрипт завершил «запустить сервис-а» ... (виноват ли это в невзрачной документации Upstart, возможно ...) — Chris Pacejo, 15 October 2013 в 20:34
@Mark Russell: Не должна ли эта normal exit 2 быть normal exit 0 2 вместо этого? Первая строка в секции script вполне четко может exit 0. — froage, 12 October 2014 в 01:45

Mark Russell · Accepted Answer · 25 July 2018 в 22:37

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Mark Russell · Accepted Answer · 26 July 2018 в 23:08

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Mark Russell · Accepted Answer · 2 August 2018 в 04:03

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Mark Russell · Accepted Answer · 4 August 2018 в 20:07

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

То, что это означает на простом английском языке: когда сигналы службы b, c или d, которые они хотят запустить, они должны ждать, пока не запустится служба-a. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения обслуживания-ожидания, теперь службы b, c и d могут свободно выполняться и выполняться.

Это заверит, что служба-a запущена и запущена до того, как попытается запустить любую из своих обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает сперва.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Mark Russell · Accepted Answer · 6 August 2018 в 04:09

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

  # service-a  -wait start on (запуск службы-b или запуск службы-c или запуск службы -d) остановка (начальная служба-a или остановленная служба-a) # Мы знаем, что у нас есть более одного задания, которое должно ждать обслуживания,  a и # будут использовать эту службу, поэтому нам нужно создать экземпляр.  экземпляр $ JOB # Необходимо сделать успешное выполнение задания, несмотря на то, что он был убит. normal status 2 task script status service-a |  grep -q "start / running" & amp; & amp; & amp; & amp;  exit 0 start service-a ||  true # Ожидание навсегда - это нормально. upstart убьет это задание, когда # служба - мы пытались начать сверху или начинать или останавливаться во время сна 3600;  делать :;  done end script

То, что это означает на простом английском языке, это: когда сигналы службы b, c или d, которые они хотят запустить, они должны дождаться, пока не будет выполнено обслуживание-a Бег. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения службы-a-wait теперь службы b, c и d могут свободно выполняться и выполняться.

Это будет гарантировать, что служба-a будет запущена и запущена до того, как начнет запускаться любая из ее обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает в первую очередь.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Mark Russell · Accepted Answer · 7 August 2018 в 22:08

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

  # service-a  -wait start on (запуск службы-b или запуск службы-c или запуск службы -d) остановка (начальная служба-a или остановленная служба-a) # Мы знаем, что у нас есть более одного задания, которое должно ждать обслуживания,  a и # будут использовать эту службу, поэтому нам нужно создать экземпляр.  экземпляр $ JOB # Необходимо сделать успешное выполнение задания, несмотря на то, что он был убит. normal status 2 task script status service-a |  grep -q "start / running" & amp; & amp; & amp; & amp;  exit 0 start service-a ||  true # Ожидание навсегда - это нормально. upstart убьет это задание, когда # служба - мы пытались начать сверху или начинать или останавливаться во время сна 3600;  делать :;  done end script

То, что это означает на простом английском языке, это: когда сигналы службы b, c или d, которые они хотят запустить, они должны дождаться, пока не будет выполнено обслуживание-a Бег. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения службы-a-wait теперь службы b, c и d могут свободно выполняться и выполняться.

Это будет гарантировать, что служба-a будет запущена и запущена до того, как начнет запускаться любая из ее обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает в первую очередь.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Mark Russell · Accepted Answer · 10 August 2018 в 10:22

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

  # service-a  -wait start on (запуск службы-b или запуск службы-c или запуск службы -d) остановка (начальная служба-a или остановленная служба-a) # Мы знаем, что у нас есть более одного задания, которое должно ждать обслуживания,  a и # будут использовать эту службу, поэтому нам нужно создать экземпляр.  экземпляр $ JOB # Необходимо сделать успешное выполнение задания, несмотря на то, что он был убит. normal status 2 task script status service-a |  grep -q "start / running" & amp; & amp; & amp; & amp;  exit 0 start service-a ||  true # Ожидание навсегда - это нормально. upstart убьет это задание, когда # служба - мы пытались начать сверху или начинать или останавливаться во время сна 3600;  делать :;  done end script

То, что это означает на простом английском языке, это: когда сигналы службы b, c или d, которые они хотят запустить, они должны дождаться, пока не будет выполнено обслуживание-a Бег. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения службы-a-wait теперь службы b, c и d могут свободно выполняться и выполняться.

Это будет гарантировать, что служба-a будет запущена и запущена до того, как начнет запускаться любая из ее обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает в первую очередь.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Mark Russell · Accepted Answer · 13 August 2018 в 16:46

Ответ Джеймса работает от 1 до 1 зависимости. Для от 1 до многих, то есть чтобы убедиться, что служба A запускается перед службами B, C и D, вам нужно использовать другой подход. Вы можете посмотреть текущие сценарии portmap для справки, но вот общий подход: создать сценарий ожидания.

Сценарий: вы хотите, чтобы ваша служба A всегда запускалась до службы-b, службы-c и службы -d.

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

  # service-a  -wait start on (запуск службы-b или запуск службы-c или запуск службы -d) остановка (начальная служба-a или остановленная служба-a) # Мы знаем, что у нас есть более одного задания, которое должно ждать обслуживания,  a и # будут использовать эту службу, поэтому нам нужно создать экземпляр.  экземпляр $ JOB # Необходимо сделать успешное выполнение задания, несмотря на то, что он был убит. normal status 2 task script status service-a |  grep -q "start / running" & amp; & amp; & amp; & amp;  exit 0 start service-a ||  true # Ожидание навсегда - это нормально. upstart убьет это задание, когда # служба - мы пытались начать сверху или начинать или останавливаться во время сна 3600;  делать :;  done end script

То, что это означает на простом английском языке, это: когда сигналы службы b, c или d, которые они хотят запустить, они должны дождаться, пока не будет выполнено обслуживание-a Бег. Запуск службы-ожидания предназначен для запуска до тех пор, пока не начнется сервис-а. После завершения службы-a-wait теперь службы b, c и d могут свободно выполняться и выполняться.

Это обеспечит запуск сервиса-a до того, как начнется запуск любой из его обратных зависимостей .

Примечание: строка «экземпляр $ JOB» важна в этом сценарии «начать ... ... или ..». В противном случае вы действительно блокируете только то, что из B, C или D срабатывает в первую очередь.

(экземпляр заслуживает лучшего объяснения честно, а теперь просто сделайте это.;)

Я не понимаю ... что мешает условию гонки между запуском службы A и службой B, продолжающей работать? Я не вижу, как выскочка узнает, что скрипт завершил «запустить сервис-а» ... (виноват ли это в невзрачной документации Upstart, возможно ...) — Chris Pacejo, 15 October 2013 в 20:34
@Mark Russell: Не следует ли, чтобы нормальный выход 2 был нормальным выходом 0 2 ? Первая строка в секции script довольно четко может выйти 0 . — froage, 12 October 2014 в 01:45

Jorge Castro · Answer 10 · 25 May 2018 в 23:29

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

это кажется мне полностью обратным. почему сценарий conf для одной службы должен быть изменен, когда другие вещи зависят от it ? — ben w, 13 March 2013 в 03:42
@benw Так что вам не нужно изменять существующие настройки служб, которыми вы не владеете. — Paccc, 31 July 2013 в 21:22
@Paccc, когда я пишу новый скрипт, который зависит от nginx, мне нужно изменить скрипт conf для nginx ... который у меня нет. — ben w, 31 July 2013 в 21:59
@benw Почему вы не используете start on (started nginx) в своем новом скрипте? — Paccc, 31 July 2013 в 22:46
@Paccc не очень. start on (started nginx) означает «начать мое обслуживание после nginx». Это не то же самое, что «запускать nginx перед моей службой, потому что это нужно». — sickill, 16 October 2014 в 14:41

Jorge Castro · Answer 11 · 25 July 2018 в 22:37

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

это кажется мне полностью обратным. почему сценарий conf для одной службы должен быть изменен, когда другие вещи зависят от it ? — ben w, 13 March 2013 в 03:42
@benw Так что вам не нужно изменять существующие настройки служб, которыми вы не владеете. — Paccc, 31 July 2013 в 21:22
@Paccc, когда я пишу новый скрипт, который зависит от nginx, мне нужно изменить скрипт conf для nginx ... который у меня нет. — ben w, 31 July 2013 в 21:59
@benw Почему вы не используете start on (started nginx) в своем новом скрипте? — Paccc, 31 July 2013 в 22:46
@Paccc не очень. start on (started nginx) означает «начать мое обслуживание после nginx». Это не то же самое, что «запускать nginx перед моей службой, потому что это нужно». — sickill, 16 October 2014 в 14:41

Jorge Castro · Answer 12 · 26 July 2018 в 23:08

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

это кажется мне полностью обратным. почему сценарий conf для одной службы должен быть изменен, когда другие вещи зависят от it ? — ben w, 13 March 2013 в 03:42
@benw Так что вам не нужно изменять существующие настройки служб, которыми вы не владеете. — Paccc, 31 July 2013 в 21:22
@Paccc, когда я пишу новый скрипт, который зависит от nginx, мне нужно изменить скрипт conf для nginx ... который у меня нет. — ben w, 31 July 2013 в 21:59
@benw Почему вы не используете start on (started nginx) в своем новом скрипте? — Paccc, 31 July 2013 в 22:46
@Paccc не очень. start on (started nginx) означает «начать мое обслуживание после nginx». Это не то же самое, что «запускать nginx перед моей службой, потому что это нужно». — sickill, 16 October 2014 в 14:41

Jorge Castro · Answer 13 · 2 August 2018 в 04:03

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

это кажется мне полностью обратным. почему сценарий conf для одной службы должен быть изменен, когда другие вещи зависят от it ? — ben w, 13 March 2013 в 03:42
@benw Так что вам не нужно изменять существующие настройки служб, которыми вы не владеете. — Paccc, 31 July 2013 в 21:22
@Paccc, когда я пишу новый скрипт, который зависит от nginx, мне нужно изменить скрипт conf для nginx ... который у меня нет. — ben w, 31 July 2013 в 21:59
@benw Почему вы не используете start on (started nginx) в своем новом скрипте? — Paccc, 31 July 2013 в 22:46
@Paccc не очень. start on (started nginx) означает «начать мое обслуживание после nginx». Это не то же самое, что «запускать nginx перед моей службой, потому что это нужно». — sickill, 16 October 2014 в 14:41

Jorge Castro · Answer 14 · 4 August 2018 в 20:07

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d0]

Например, файл конфигурации Upstart /etc/init/centrify.conf может сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого в английский, это будет означать, что:

начать с (начало cron или запуск autofs или начало nis)

запустите службу Centrify как раз перед cron, autofs или nis start (в зависимости от того, что начинается сначала).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, что начинается с первого запуска, тем самым гарантируя, что Centrify будет запущен до того, как любой из эти сервисы начинаются.

Обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify не установит sta запущен.

это кажется мне полностью обратным. почему сценарий conf для одной службы должен быть изменен, когда другие вещи зависят от it ? — ben w, 13 March 2013 в 03:42
@benw Так что вам не нужно изменять существующие настройки служб, которыми вы не владеете. — Paccc, 31 July 2013 в 21:22
@Paccc, когда я пишу новый скрипт, который зависит от nginx, мне нужно изменить скрипт conf для nginx ... который у меня нет. — ben w, 31 July 2013 в 21:59
@benw Почему вы не используете start on (started nginx) в своем новом скрипте? — Paccc, 31 July 2013 в 22:46
@Paccc не очень. start on (started nginx) означает «начать мое обслуживание после nginx». Это не то же самое, что «запускать nginx перед моей службой, потому что это нужно». — sickill, 16 October 2014 в 14:41

Jorge Castro · Answer 15 · 6 August 2018 в 04:09

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d2]

Например, файл конфигурации Upstart /etc/init/centrify.conf мог бы сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого слова в английский язык будет выглядеть следующим образом:

запустите службу Centrify перед либо cron, autofs или nis start (в зависимости от того, что начинается с первого раза).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, как начнется сервис сначала, Centrify запускается до запуска любой из этих служб.

Также обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify начал работать.

Очень элегантный и простой, как только вы привыкли думать таким образом.

Jorge Castro · Answer 16 · 7 August 2018 в 22:08

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d2]

Например, файл конфигурации Upstart /etc/init/centrify.conf мог бы сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого слова в английский язык будет выглядеть следующим образом:

запустите службу Centrify перед либо cron, autofs или nis start (в зависимости от того, что начинается с первого раза).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, как начнется сервис сначала, Centrify запускается до запуска любой из этих служб.

Также обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify начал работать.

Очень элегантный и простой, как только вы привыкли думать таким образом.

Jorge Castro · Answer 17 · 10 August 2018 в 10:22

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d2]

Например, файл конфигурации Upstart /etc/init/centrify.conf мог бы сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого слова в английский язык будет выглядеть следующим образом:

запустите службу Centrify перед либо cron, autofs или nis start (в зависимости от того, что начинается с первого раза).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, как начнется сервис сначала, Centrify запускается до запуска любой из этих служб.

Также обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify начал работать.

Очень элегантный и простой, как только вы привыкли думать таким образом.

Jorge Castro · Answer 18 · 13 August 2018 в 16:46

Решение заключается в том, чтобы подойти к проблеме с другого направления: чтобы удовлетворить критериям начала для Centrify, нет необходимости зависеть от того, что существующие службы зависят от новой службы Centrify, а скорее заставляет новую службу Centrify зависеть от существующих сервисов. [ ! d2]

Например, файл конфигурации Upstart /etc/init/centrify.conf мог бы сказать:

начать (начало cron или запуск autofs или начало nis)

Преобразование этого слова в английский язык будет выглядеть следующим образом:

запустите службу Centrify перед либо cron, autofs или nis start (в зависимости от того, что начинается с первого раза).

Порядок, в котором cron, autofs или nis start не имеет значения: Upstart гарантирует, что Centrify начнет работу до того, как начнется сервис сначала, Centrify запускается до запуска любой из этих служб.

Также обратите внимание, что Upstart заблокирует начало первой службы, которая хочет начать, пока Centrify начал работать.

Очень элегантный и простой, как только вы привыкли думать таким образом.

это кажется мне полностью обратным. почему сценарий conf для одной службы должен быть изменен, когда другие вещи зависят от it ? — ben w, 13 March 2013 в 03:42
@benw Так что вам не нужно изменять существующие настройки служб, которыми вы не владеете. — Paccc, 31 July 2013 в 21:22
@Paccc, когда я пишу новый скрипт, который зависит от nginx, мне нужно изменить скрипт conf для nginx ... который у меня нет. — ben w, 31 July 2013 в 21:59
@benw Почему вы не используете start on (запущен nginx) в новом скрипте? — Paccc, 31 July 2013 в 22:46
@Paccc не очень. start on (начальный nginx) означает «начать мое обслуживание после nginx». Это не то же самое, что «запускать nginx перед моей службой, потому что это нужно». — sickill, 16 October 2014 в 14:41

Как я могу убедиться, что одно стартовое задание начинается перед другими заданиями Upstart?

18 ответов

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

Решение: создать сценарий ожидания для службы A. Назовите его «/etc/init/service-a-wait.conf"

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

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