Cron job running at wrong time

Forums › Linux › Cron job running at wrong time

PANiCnz

990 posts

Ultimate Geek

#289024 7-Aug-2021 16:33

I'm trying to configure a simple cron job on Ubuntu 20.04 that will run a shell script each morning at 2am. The cron job is running, but its running at 2pm each day.

This is the entry in the crontab:

0 2 * * * /home/panicnz/backup.sh

And I've check the time is correct on the server.

Any ideas what's going wrong?

Jiriteach

1119 posts

Uber Geek

ID Verified

Lifetime subscriber

#2756569 7-Aug-2021 17:21

Have you checked your timezone is correctly set?

-- opinions expressed by me are solely my own. ie - personal

qwerty123

147 posts

Master Geek

#2756574 7-Aug-2021 17:43

It seems tz is set to UTC

Jiriteach

1119 posts

Uber Geek

ID Verified

Lifetime subscriber

#2756575 7-Aug-2021 17:45

qwerty123: It seems tz is set to UTC

Yup which would align with what you seeing since we’re 12 hours ahead of UTC. Change the tz to NZ.

-- opinions expressed by me are solely my own. ie - personal

jlittle

188 posts

Master Geek

ID Verified

Subscriber

#2756578 7-Aug-2021 18:14

Bear in mind that cron jobs do not run your login scripts and so have a very bare-bones environment. Your script must set up any environment variables it uses. If it works from a login shell it might not work being run by cron. First bitten by that decades ago. On my 21.04 cron jobs get only 7 variables, and the PATH is vanilla.

You say you've checked the time on the server, did you look at /etc/localtime?

ls -l /etc/localtime

PANiCnz

990 posts

Ultimate Geek

#2756579 7-Aug-2021 18:19

The timezone was set incorrectly when the cron job was configured, but changed afterwards. I've delete the cronjob and recreated it with the correct timezone set. Fingers crossed that's enough.

Its a pretty simple script, it stops all containers, rsync's some folders to a NFS share, and restarts the containers. So far the script work as it should.

fe31nz

1232 posts

Uber Geek

#2756634 7-Aug-2021 23:56

These days systemd timer units can be a better option than cron jobs. They are even more flexible and you have more control over the running environment. As an example, I run a script that does hourly checks for sufficient free space on my system partition. It consists of two files, a .service unit and a .timer unit. As the .service unit is set to "enabled", it will also run the script immediately after bootup as well as when specified by the .timer unit. If the script fails (there is insufficient free space), the OnFailure= line runs a service that emails me to tell me there is a problem. This is generic email service that is used by a number of my systemd units.

root@mypvr:/etc/systemd/system# systemctl cat check-free-space
# /etc/systemd/system/check-free-space.service
[Unit]
Description=Check free space on /
After=time-sync.target
OnFailure=notify-failure@%n.service

[Service]
ExecStart=/bin/bash -c "/usr/local/bin/check-free-space.sh"

[Install]
WantedBy=multi-user.target

root@mypvr:/etc/systemd/system# systemctl cat check-free-space.timer
# /etc/systemd/system/check-free-space.timer
[Unit]
Description=Hourly root free space check.

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target