2

I created a cronjob in the following way to run a script. The script started a service only if it was down.

Here is the script, 

#!/bin/bash
service=influxdb

if (( $(ps -ef | grep -v grep | grep $service | wc -l) > 0 ))
then
echo "$service is running!!!"
else
service $service start
fi

I created a cron job like this, 

alphauser@AlphaServer:~$ sudo crontab -e

And then added this line

* * * * * bash /home/alphauser/influx-start.sh > /home/alphauser/output-influx-start.txt

I stored the output in a file just to check its output.

The service stopped and now it was the time for cron to show its magic. But it failed to start the service. I saw the output file and this was written in that,

Starting influxdb...
influxdb process was unable to start [ FAILED ]

then I removed this cronjob from by sudo crontab -r.

I added this line at the end of etc/crontab file i.e,

* * * * * root bash /home/alphauser/influx-start.sh > /home/alphauser/outputinflux.txt

and it worked. The service started and This was the output,

influxdb is running!!!

I want to know that why it failed with sudo crontab -e but it worked with etc/crontab file.

The authentication of sudo cannot be the issue because I added it in the sudo crontab and by chance if that would have been the case, it would have said You must be root to run this script.

luv.preet
  • 5,787
  • 1
    does not sudo crontab -e means that it should be run by root ? – luv.preet Apr 21 '17 at 14:46
  • I read on this site that to run as root add by sudo crontab -e , and those answers were upvoted. – luv.preet Apr 21 '17 at 14:48
  • https://askubuntu.com/questions/419548/how-to-setup-a-root-cron-job-properly – luv.preet Apr 21 '17 at 14:49
  • 2
    The service commands (which you should really move away from using btw - since 16.04 is systemd based) are in /usr/sbin - which is not in in root's personal crontab PATH but is added to PATH in /etc/crontab – steeldriver Apr 21 '17 at 14:57
  • @Terrance for the record, I run jobs from sudo crontab -e as root all the time. – Jos Apr 21 '17 at 15:06
  • Well, what do you know. Adding the full PATH and SHELL statements from the /etc/crontab file to the sudo crontab -e file actually worked. – Terrance Apr 21 '17 at 15:20

1 Answers1

5

As @steeldriver noticed: the service command fails because it is not in the crontab path. Even as root, crontab jobs run in an environment that is fairly restricted in terms of environmental variables. You need to include the full path of many executables in a command that is to be executed by cron.

In this case, therefore, 

/usr/sbin/service $service start

would have worked. How do we know what the exact path of an executable is? Do which service and it will answer /usr/sbin/service.

However, the service command is on its way out and being replaced by its systemd equivalent systemctl. You would do systemctl start $service in a terminal command. Even without sudo, systemctl will figure out that it is not running as root, and ask for your sudo password.

In a crontab, you would use the full path to systemctl utility, which is /bin/systemctl.

So, if you use 

/bin/systemctl start $service

it should work.

Jos
  • 29,224
  • Good answer! Makes sense to have the full path to the command to work. My problem I bumped into was a script I have that uses iptables deeper in another script needed to be called via sudo. So, without changing my other script to call the full path to iptables, my script was failing in the sudo crontab -e but not in the /etc/crontab file since the PATH was set in the latter. Setting the PATHs in my sudo crontab -e made it so I didn't have to change my script. – Terrance Apr 21 '17 at 15:42