Является ли выскочка надежной заменой анакрону?

Начиная с версии Upstart 1.10 (используется в Ubuntu 13.10):

Upstart текущая документация находится на http://upstart.ubuntu.com/cookbook

Функциональность Cron и Anacron еще не была реализована в Upstart.

Ссылка: http://upstart.ubuntu.com/cookbook/

11.26 Запускать работу периодически

В настоящее время это не может быть обработано Upstart напрямую. Тем не менее, функция "Temporal Events", над которой сейчас ведется работа, решит эту проблему.

Пока не появятся временные события, вы должны либо использовать cron(8), либо что-то вроде:

 # /etc/init/timer.conf

 instance $JOB_TO_RUN

 script   for var in SLEEP JOB_TO_RUN   do
     eval val=\${$var}
     if [ -z "$val" ]
     then
       logger -t $0 "ERROR: variable $var not specified"
       exit 1
     fi   done

   eval _sleep=\${SLEEP}   eval _job=\${JOB_TO_RUN}

   while [ 1 ]   do
     stop  $_job || true
     sleep $_sleep
     start $_job || true   done end script

Индивидуальные задачи могут относиться к 1) запуску задания от имени пользователя [Upstart делает это] или 2) генерации и прослушиванию событий уровня пользователя вместо системных событий [Upstart делает это тоже]

Работа в качестве пользователя описана по адресу http://upstart.ubuntu.com/cookbook/.

11.43.2 Изменение пользователя

Некоторые демоны начинают работать как суперпользователь, а затем внутренне организуют передачу своего уровня привилегий другому (менее привилегированному) пользователю. Однако некоторым демонам это не нужно: им никогда не нужны привилегии root, поэтому их можно вызывать как пользователь без полномочий root.

Как вы запускаете "системное задание", но тогда оно запускается от имени пользователя без полномочий root? Начиная с версии Upstart 1.4, Upstart имеет возможность запускать системное задание от имени указанного пользователя, используя разделы setuid и setgid.

Однако, если вы не используете Upstart 1.4, легко достичь требуемой цели. Есть несколько методов, которые вы можете использовать. Рекомендуемый метод для систем Debian и Ubuntu - использовать вспомогательную утилиту start-stop-daemon(8) следующим образом:

 exec start-stop-daemon --start -c myuser --exec command

Преимущество использования start-stop-daemon(8) состоит в том, что он просто меняет пользователя и группу, под которой запускается команда. Это также имеет преимущество перед su(1) в том, что su(1) должен быть разветвленным, чтобы иметь возможность держать сеанс PAM открытым, и поэтому upstart сложнее отследить, тогда как start-stop-daemon(8) просто выполнит данная команда после изменения uid / gid.

Другая потенциальная проблема, о которой следует знать, это то, что start-stop-daemon не накладывает ограничения PAM ("Pluggable Authentication Module") на процесс, который он запускает. Такие ограничения могут быть установлены с помощью соответствующих разделов Upstart, вы просто не можете указать пределы через PAMs limit.conf(5).

Конечно, вы можете захотеть установить ограничения PAM, и в этом случае вы должны использовать su(1) или sudo(8), оба из которых связаны с библиотеками PAM.

Общий совет - НЕ использовать su(1) или sudo(8), поскольку ограничения PAM действительно не подходят для системных служб. Например, PAM будет делать запись wtmp (5) каждый раз, когда вызывается su(1) или sudo(8), и эти записи не подходят для системных служб.

Если вы хотите использовать su(1) или sudo(8), приведенные ниже примеры покажут вам, как это сделать.

Используя su(1):

 exec su -s /bin/sh -c command $user

Обратите внимание, что хотя вы могли бы упростить приведенное выше до следующего, это не рекомендуется, поскольку, если пользователь "$user" является системной учетной записью с оболочкой, заданной как / bin / false, задание не будет запускать указанную команду: оно завершится неудачно из-за в / bin / false, возвращая "1":

 exec su -c command $user

Задание завершится сбоем, если пользователь "$user" является системной учетной записью с оболочкой, указанной как / bin / false.

Чтобы избежать форка (2), вызванного порождением оболочки, вы могли бы вместо этого указать:

 exec su -s /bin/sh -c 'exec "$0" "$@"' $user -- /path/to/command
 --arg1=foo -b wibble

Этот метод особенно полезен, если ваша работа - это работа по обслуживанию, которая использует ожидания.

Базовый пример использования sudo(8):

 exec sudo -u $user command

Задания на уровне пользователя (называемые "заданиями сеанса") описаны по адресу http://upstart.ubuntu.com/cookbook/.

4.2.3. Сеансовая работа

Начиная с Upstart v1.7

Задания сеанса аналогичны заданиям старого пользователя. В отличие от старых заданий пользователя, заданиями сеанса не управляет Upstart, работающий как PID 1 - они управляются собственным сеансом Init пользователей.

В отличие от того, когда Upstart запускается как PID 1, Session Init может читать свои файлы конфигурации задания из нескольких каталогов. Список заданий каталогов читается из следующего (по порядку):

 $XDG_CONFIG_HOME/upstart/ (or $HOME/.config/upstart/ if $XDG_CONFIG_HOME not set).
 $HOME/.init/ (deprecated - supported for legacy User Jobs).
 $XDG_CONFIG_DIRS
 /usr/share/upstart/sessions/

Имя каждого задания принимается за базовое имя, когда любое из названных выше каталогов было удалено. Например, если файл конфигурации задания существует как $HOME/.config/upstart/hello/world.conf, его имя будет "hello/world", тогда как если файл конфигурации задания существует как / usr / share / upstart / session / foo / bar.conf, его имя будет "foo / bar".

Upstart разрешает любые конфликты имен, просто принимая первое допустимое задание (или файл переопределения), которое оно находит. Например, если существуют следующие два файла:

 $HOME/.init/foo.conf $HOME/.config/upstart/foo.conf

Только первый, $HOME/.init/foo.conf будет использоваться. Принимая во внимание, что если существуют следующие файлы:

 $HOME/.init/foo.conf $HOME/.config/upstart/foo.conf
 $HOME/.config/upstart/foo.override

Upstart сначала прочитает $HOME/.init/foo.conf, а затем применяет любые изменения в $HOME/.config/upstart/foo.override.