TL; DR
You need to add /sbin to cron PATH so that the service script can find initctl . To do this, add a definition like this to the top of your crontab:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
You may have problems with cron via email, since initctl exit with status 1 (crash) if the job you are trying to start is already running. You can get around this with something like:
45 23 * * * service bormarise_celery_daemon status | grep -q running || service bormarise_celery_daemon start
Although it is a little long, it should try to run the start command if the bormarise_celery_daemon service bormarise_celery_daemon not running.
service vs initctl
While the service command attempts to manage Upstart jobs, this is not the actual Upstart control function — it will be initctl and the associated package of short commands (i.e. start , stop , etc.). All Upstart scripts are located in /sbin/ .
The service team is trying to make it easier for people to distribute services between Upstart and Classic SysV scripts. Thus, you can use one interface ( service script) to manage the services of both systems.
Enable Script Service
If you are viewing the actual source of the service script (this is just a Bash script) on Ubuntu 14.04, you will see:
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null \ && initctl version | grep -q upstart then # Upstart configuration exists for this job and we're running on upstart case "${ACTION}" in start|stop|status|reload)
Opening condition:
- Checks if the service you specified (in your case:
bormarise_celery_daemon ) is an Upstart job. Upstart tasks go into /etc/init/ with the extension .conf . - If so, the
service script will check if it can run initctl . - If possible, a
service script, then make sure that initctl is the version with the new commons.
If all of this is true, then the service script will try to use the appropriate initctl command to run the Upstart job. For instance:
service bormarise_celery_daemon start
means:
start bormarise_celery_daemon
which is (basically) equivalent to:
initctl start bormarise_celery_daemon
However , if any of these conditions is incorrect, the service script assumes that you are trying to run the SysV-style script. These are just Bash scripts located in /etc/init.d/ . However, if such a script does not exist, it will exit with an unrecognized service error message.
Putting the pieces together
By default, the PATH for cron contains only /bin/ and /usr/bin/ . This means that it does not include /sbin/ , where the initctl executable is located. This means that cron will not be able to run initctl .
When cron starts your crontab, service script can find your Upstart job, but can not start initctl , so it skips trying to start your service through Upstart (i.e., initctl ). Instead, he tries to look for the sysv script style in /etc/init.d/ . Since the script does not exist, the service script issues and displays your error message.
If you override the default cron PATH with one that includes /sbin/ , then the service script will be able to find initctl and try to run your Upstart job.
Interestingly, on Ubuntu 12.04, the service script only checks if the Upstart job exists by omitting both initctl checks. This means that if you try to do this on Ubuntu 12.04, it will try to use Upstart to start your service. However, if /sbin/ not in the way, it will fail with a (slightly) more understandable error message:
/usr/bin/service: 123: exec: start: not found