Score:1

Cron Job Not Running on Ubuntu 20.04.2 LTS

cl flag

I have created a Cron job to run a script that checks if a process is running, in case it does it just print that the process is running, if not it prints out the process is not running and restart the process:

#!/bin/sh

SERVICE="start_server.py"
if ps -ef | grep "$SERVICE" | grep -v grep >/dev/null
then
    echo "start_server.py is running"
else
    echo "start_server.py stopped"
    python2.7 start_server.py &
fi

As user Ubuntu I created the following cron job by running - crontab -e

* * * * * /home/ubuntu/mislaka/check_process.sh 2>&1 /home/ubuntu/mislaka/script_log.log

For some reason, it is not working or writing the output to the log file.

Tried restarting cron service, tried creating the cron job as root, changed all the permission and the user who is running the script yet nothing is working.

The script if I run it by itself works as expected.

Ubuntu Version:

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:        20.04
Codename:       focal

Thanks in advance

uz flag
Jos
Your redirection is wrong. Replace `2>&1` by `>>` and add `2>&1` at the end.
FedKad avatar
cn flag
Or replace `2>&1` with just `&>>`.
in flag
The “As user Ubuntu I created the following cron job” may be an issue as the cron job will only run when that user is logged in. Generally these sorts of jobs are done as `root`: `sudo crontab -e`
hr flag
@FedonKadifeli afaik that will only work if they set `SHELL=/bin/bash` in the crontab (the default is `/bin/sh`)
hr flag
@matigo afaik that's not correct - cron runs as a daemon and users do not need to be logged in for their crontabs to be read
Avihai avatar
cl flag
@guiverc Sorry for the miss informatiom: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Codename: focal
rattkin avatar
fm flag
If you would proven and reliable solution, look at monitoring software like monit. It is configured by a simple ext file and it can watch your process and restart it, send e-mail. It can also watch free disk space, if disk is full, that is source of many possible problems in production.
Avihai avatar
cl flag
@guiverc I changed the title as suggested
Score:1
it flag

Jobs run through cron, or systemd startup scripts aren't run in the same runtime environment that you have on your desktop. systemd startup scripts are run as root. None of your PATH changes, or other environment variable settings are automatically propagated to your cron job. For example, there's no $DISPLAY, so GUI programs need special treatment (read man xhost).

One can set environment variables for all one's cron jobs in the crontab file Read man 5 crontab.

Look at the results of echo "=== id ===";id;echo "=== set ===";set;echo "=== env ===";env | sort;echo "=== alias ===";alias in each of your environments.

Since the command part of the crontab line is, by default, interpreted by /bin/sh, which has a simpler syntax than /bin/bash, I recommend having command be a call to a bash script (executable, mounted, starts with #!/bin/bash) which sets up the environment, then calls the desired program.

Avihai avatar
cl flag
I started with /bin/bash and it did not work as well.
Score:0
cl flag

The issue was that I needed to change my script and edit the cron job to run the correct script and added full path to the script.

Score:0
in flag

You can check like this:

  1. first run service cron status to check the status.

  2. write a test string to the mycommand.log file every minute to check whether the cron is working.
    run crontab -e and add the following content at the end: */1 * * * * echo test > /tmp/mycommand.log 2>&1 save and close then check the content in the /tmp/mycommand.log file.

  3. restart the cron service after you change your time or timezone to make sure the cron runs on time. run service cron restart

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.