I'm working with some code that fires up cron on a server (which doesn't have it running at boot time). The script which starts cron sets up some logging stuff and then simply invokes cron
. It doesn't use /etc/init.d/cron
or service cron start
.
After starting cron this way, service cron status
and service cron stop
seem to be happily able to work, and the PIDFILE specified in /etc/init.d/cron
is present.
I put a log line into /etc/init.d/cron
, and it looks like running cron
standalone does not invoke the script.
# service cron status
script is running
* cron is running
# service cron stop
script is running
* Stopping periodic command scheduler cron [ OK ]
# cron
#
What's going on here? Is this simply because the cron
binary and the /etc/init.d/cron script use the same convention for the location of the pidfile?
Your hypothesis is correct: Vixie Cron has a fixed pidfile location (
/var/run/crond.pid
), which also prevents running it twice.The init.d script, which is also called by
service
uses the standard/lib/lsb/init-functions
, which sum up to:start
action just calls/usr/sbin/cron
(through the/sbin/start-stop-daemon
helper),stop
action just sendsSIGTERM
to the PID in the pidfile (through/sbin/start-stop-daemon
),status
action amounts tokill -0 $(cat /var/run/crond.pid)
.However, if you have systemd installed, the standard init functions are rewritten in
/lib/lsb/init-functions.d/40-systemd
and running cron directly is not detected any more:since systemd would like to have a
CGroup
per service. What is worsestart
andrestart
won't work, since cron will fail on the already existing pidfile andstop
will not kill the cron instance you created.