Cronjobs not executing

[kalekulan]

Hi,

I'm trying to setup a nightly cronjob to put my server to sleep. It doesn't execute, but works fine using the command line.

Syslog doesn't give me anything, neither does journalctl. I tried increasing the log level but that doesn't change things either.

➜crontab -e
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6    * * 7   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6    1 * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }
27 11   * * *   root    /usr/sbin/rtcwake -m off -s 60

➜cat /etc/default/cron
# Cron configuration options

# Whether to read the system's default environment files (if present)
# If set to "yes", cron will set a proper mail charset from the
# locale information. If set to something other than 'yes', the default
# charset 'C' (canonical name: ANSI_X3.4-1968) will be used.
#
# This has no effect on tasks running under cron; their environment can
# only be changed via PAM or from within the crontab; see crontab(5).
READ_ENV="yes"

# Extra options for cron, see cron(8)
#
# For example, to enable LSB name support in /etc/cron.d/, use
# EXTRA_OPTS='-l'
#
# Or, to log standard messages, plus jobs with exit status != 0:
EXTRA_OPTS='-L 5'
#
# For quick reference, the currently available log levels are:
#   0   no logging (errors are logged regardless)
#   1   log start of jobs
#   2   log end of jobs
#   4   log jobs with exit status != 0
#   8   log the process identifier of child process (in all logs)
#
#EXTRA_OPTS=""

➜ journalctl -b -g cron
Sep 11 09:18:31 proxmox systemd[1]: Started cron.service - Regular background program processing daemon.
Sep 11 09:18:31 proxmox cron[1614]: (CRON) INFO (pidfile fd = 3)
Sep 11 09:18:31 proxmox cron[1614]: (CRON) INFO (Running @reboot jobs)
Sep 11 09:18:31 proxmox CRON[1617]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Sep 11 09:19:31 proxmox CRON[1617]: pam_unix(cron:session): session closed for user root
Sep 11 10:17:01 proxmox CRON[45479]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Sep 11 10:17:01 proxmox CRON[45480]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Sep 11 10:17:01 proxmox CRON[45481]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Sep 11 10:17:01 proxmox CRON[45482]: (root) CMD (root^Icd / && run-parts --report /etc/cron.hourly)
Sep 11 10:17:01 proxmox CRON[45479]: pam_unix(cron:session): session closed for user root
Sep 11 10:17:01 proxmox CRON[45480]: pam_unix(cron:session): session closed for user root
Sep 11 11:17:01 proxmox CRON[78228]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Sep 11 11:17:01 proxmox CRON[78229]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Sep 11 11:17:01 proxmox CRON[78230]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Sep 11 11:17:01 proxmox CRON[78231]: (root) CMD (root^Icd / && run-parts --report /etc/cron.hourly)
Sep 11 11:17:01 proxmox CRON[78228]: pam_unix(cron:session): session closed for user root
Sep 11 11:17:01 proxmox CRON[78229]: pam_unix(cron:session): session closed for user root
Sep 11 11:22:14 proxmox systemd[1]: Stopping cron.service - Regular background program processing daemon...
Sep 11 11:22:14 proxmox systemd[1]: cron.service: Deactivated successfully.
Sep 11 11:22:14 proxmox systemd[1]: Stopped cron.service - Regular background program processing daemon.
Sep 11 11:22:14 proxmox systemd[1]: Started cron.service - Regular background program processing daemon.
Sep 11 11:22:14 proxmox cron[84070]: (CRON) INFO (pidfile fd = 3)
Sep 11 11:22:14 proxmox cron[84070]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
Sep 11 11:23:42 proxmox systemd[1]: Stopping cron.service - Regular background program processing daemon...
Sep 11 11:23:42 proxmox systemd[1]: cron.service: Deactivated successfully.
Sep 11 11:23:42 proxmox systemd[1]: Stopped cron.service - Regular background program processing daemon.
Sep 11 11:23:42 proxmox systemd[1]: Started cron.service - Regular background program processing daemon.
Sep 11 11:23:42 proxmox cron[86094]: (CRON) INFO (pidfile fd = 3)
Sep 11 11:23:42 proxmox cron[86094]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
Sep 11 11:24:01 proxmox cron[86094]: (root) RELOAD (crontabs/root)
Sep 11 11:25:01 proxmox CRON[88939]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Sep 11 11:25:01 proxmox CRON[88939]: pam_unix(cron:session): session closed for user root
Sep 11 11:27:01 proxmox cron[86094]: (root) RELOAD (crontabs/root)
Sep 11 11:27:01 proxmox CRON[93390]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Sep 11 11:27:01 proxmox CRON[93390]: pam_unix(cron:session): session closed for user root

 

[UdoB]

nightly cronjob

This:

27 11 * * *

...means 27 minutes after 11 a.m. ;-)

----
Edit: okay, you probably put that in there just for testing. Sorry, no further help...

 

[LostOnTheLine]

I was unable to get cronjobs to run in Proxmox. I noticed when I crontab -e I get nano showing a file like /tmp/crontab.RWLxDc/crontab. It will be different each time but has the previously edited jobs in it, so it is saving, but it does not seem to run at all.

With the help of Grok I discovered that Systemd Services do run scheduled on my Proxmox machines. From my understanding that's the best way to cron in Proxmox if not the only way. It's a lot more complicated to setup, but ask Grok, ChatGPT, Claude, or whatever AI you prefer for help converting your desired service.

For my example I was running the Scrutiny SMART collector service on each node every hour. You could adopt it to your own needs but I'll give you this as an example
From cronjob this was

33 * * * * /usr/local/bin/scrutiny-collector-metrics-linux-amd64 run --api-endpoint "http://192.168.1.101:8080" --host-id "Proxmox-Machine1" --log-file /var/log/scrutiny-collector_Prox-Machine1.log

• Step 1: Create a Systemd Service for Scrutiny Collector

Create a new systemd service file:

nano /etc/systemd/system/scrutiny-collector.service

[Unit]
Description=Scrutiny Collector
After=network.target

[Service]
ExecStart=/usr/local/bin/scrutiny-collector-metrics-linux-amd64 run --api-endpoint "http://192.168.1.101:8080" --host-id "Proxmox-Machine1" --log-file /var/log/scrutiny-collector_Prox-Machine1.log
Restart=always
User=root
WorkingDirectory=/usr/local/bin
StandardOutput=append:/var/log/scrutiny-collector_Prox-Machine1.log
StandardError=append:/var/log/scrutiny-collector_Prox-Machine1.log

[Install]
WantedBy=multi-user.target

• Step 2: Create a Systemd Timer for Hourly Execution

Create a timer file:

nano /etc/systemd/system/scrutiny-collector.timer

[Unit]
Description=Run Scrutiny Collector Every Hour

[Timer]
OnCalendar=*:33
Persistent=true

[Install]
WantedBy=timers.target

• Step 3: Reload Systemd and Enable the Timer

sudo systemctl daemon-reload
sudo systemctl enable scrutiny-collector.timer
sudo systemctl start scrutiny-collector.timer

Step 4: Verify It's Running

systemctl list-timers --all | grep scrutiny

 

[BobhWasatch]

I was unable to get cronjobs to run in Proxmox. I noticed when I crontab -e I get nano showing a file like /tmp/crontab.RWLxDc/crontab. It will be different each time but has the previously edited jobs in it, so it is saving, but it does not seem to run at all.

The different file thing is because crontab -e copies the current settings into a temporary file for editing. It is perfectly normal. Have you used Linux before? Did you ask for help?

The usual way to run something once per hour on Debian-based systems like PVE is to drop a regular bash script into /etc/cron.hourly and make it executable with "chmod a+rx <file>". You might also have to adjust the PATH variable in your script, or specify exact paths, because cron runs with a reduced PATH. That method works perfectly fine for me.

What you've done works, Leonard Poettering would be proud, but it is unnecessarily complicated.

ETA: I will also say that asking Grok for anything is pretty inferior to just asking here. You are much more likely to get a correct answer, as opposed to garbage that sounds nice.

 

[LostOnTheLine]

What you've done works, Leonard Poettering would be proud, but it is unnecessarily complicated.

ETA: I will also say that asking Grok for anything is pretty inferior to just asking here. You are much more likely to get a correct answer, as opposed to garbage that sounds nice.

Well Crontab didn't work. digging into & figuring out why is MORE complicated. I tried a couple different things in crontab -e & all failed to run. Grok gave me an answer immediately instead of requiring me to wait for someone to reply. This post from half a year ago, didn't have a solution. The OP had a similar issue & nobody gave them an answer. I had a similar issue to the OP, crontab not running, & I found a handful of similar posts, but no solution. I spent maybe an hour or less troubleshooting with Grok & had a workable solution.

So

---

Grok Advantages

• Immediate Response
• Real Time troubleshooting
• Doesn't feel the need to tell you that it's better than you
• Gets an answer fairly quickly
• Helps you understand why it does things the way it does

Forum Advantages

• Will eventually give a better reply most likely... If you can weed through all the high-minded BS & ego stroking
• ...

---

Grok Disadvantages

• May be more complicated solution than needed
• Often takes a couple tried to get it right

Forum Disadvantages

• May be hours or days later before you get a reply
• 50% change will tell you you are stupid for not being them
• Usually spends time telling you you are dumb & may eventually give an answer
• Answers are 50% chance of being incomplete assuming you know everything the poster knows
• Answers are usually "Do this" without explaining why

---

more likely to get a correct answer, as opposed to garbage that sounds nice

It's really funny that the "garbage that sounds nice" is the one that actually works while the "correct answer" is incomplete, not explicitly explained, requires you to fiddle with things & hope they actually work, has less control, & just does a good-enough job rather than what was actually desired.

The different file thing is because crontab -e copies the current settings into a temporary file for editing. It is perfectly normal. Have you used Linux before? Did you ask for help?

Except I cannot verify it & it fails to run... The temp file I've seen before, sure, but not always, in fact I'd say half the time st modt, but maybe I'm just more used to a different system when Croning. I've had a number of Cron-not-running issues, particularly in Docker, when TMP-Cron is involved, so it immediately makes me say "Is it even going to run?" & lo & behold it didn't.

The usual way to run something once per hour on Debian-based systems like PVE is to drop a regular bash script into /etc/cron.hourly and make it executable with "chmod a+rx <file>". You might also have to adjust the PATH variable in your script, or specify exact paths, because cron runs with a reduced PATH. That method works perfectly fine for me.

You have less control over /etc/cron.hourly, for the particular program I'm running, not a script, just an executable with flags, I want it to run at a specific minute every hour. The same runs on every system & I can see that it ran at X:07 so I know it's for that particular group, or X:15 for a different group. I need to run a binary that also needs to have access to smartctl. The path is called directly /usr/local/bin/scrutiny-collector-metrics-linux-amd64 & it doesn't run when set with crontab -e. I tried a few others & they didn't either. & as far as "The usual way" I'll 100% contend that cron.hourly is NOT the "usual" way, using the standard crontab is the standard way to do it.