Я работаю с некоторым кодом, который запускает cron на сервере (на котором он не работает во время загрузки). Скрипт, который запускает cron, устанавливает некоторые записи, а затем просто вызывает cron
. Он не использует /etc/init.d/cron
или service cron start
.
После запуска cron таким образом, service cron status
и service cron stop
кажутся вполне работоспособными, и PIDFILE, указанный в /etc/init.d/cron
настоящее.
Я ввел строку журнала в /etc/init.d/cron
, и похоже на бег cron
standalone не вызывает скрипт.
# service cron status
script is running
* cron is running
# service cron stop
script is running
* Stopping periodic command scheduler cron [ OK ]
# cron
#
Что тут происходит? Это просто потому, что cron
двоичный файл и сценарий /etc/init.d/cron используют одно и то же соглашение для расположения файла pid?
Ваша гипотеза верна: Викси Крон имеет фиксированное расположение pid-файла (/var/run/crond.pid
), что также предотвращает его запуск дважды.
В init.d скрипт, который также вызывается service
использует стандартный /lib/lsb/init-functions
, которые в сумме составляют:
start
действие просто призывает /usr/sbin/cron
(сквозь /sbin/start-stop-daemon
помощник),stop
действие просто отправляет SIGTERM
к PID в pidfile (через /sbin/start-stop-daemon
),status
действие сводится к kill -0 $(cat /var/run/crond.pid)
.Однако, если у вас есть systemd установлен, стандартные функции инициализации переписаны в /lib/lsb/init-functions.d/40-systemd
и бег cron напрямую больше не обнаруживается:
piotr@bialykiel:~$ sudo /usr/sbin/cron
piotr@bialykiel:~$ sudo /etc/init.d/cron status
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Sun 2020-02-02 09:12:43 CET; 5min ago
Docs: man:cron(8)
Process: 734 ExecStart=/usr/sbin/cron -f $EXTRA_OPTS (code=killed, signal=TERM)
Main PID: 734 (code=killed, signal=TERM)
поскольку systemd хотел бы иметь CGroup
за услугу. Что хуже start
и restart
не будет работать, так как cron потерпит неудачу в уже существующем pidfile и stop
не убьет cron экземпляр, который вы создали.