What is the correct way to get cron to read the new crontab ?
With emacs I made a change to /etc/crontab on a Debian 11
workstation. I have done this before successfully.
After the change I ran
systemctl restart cron && systemctl status cron
But now the change doesn't take effect.
I tried systemctl reload cron, but got the reply "Failed to reload cron.service: Job type reload is not applicable for unit
cron.service".
What is the correct way to get cron to read the new crontab ?
Thanks, Roger
Roger Price <debian@rogerprice.org> wrote:
With emacs I made a change to /etc/crontab on a Debian 11
When you say you made a change with emacs, what command did you run?
What you are supposed to do is use the command crontab to start the
editor of your choice.
With emacs I made a change to /etc/crontab on a Debian 11 workstation. I have done this before successfully. After the change I ran
systemctl restart cron && systemctl status cron
But now the change doesn't take effect.
I tried systemctl reload cron, but got the reply "Failed to reload cron.service: Job type reload is not applicable for unit cron.service".
What is the correct way to get cron to read the new crontab ?
I rediscovered command EDITOR=emacs crontab -e and made my changes.
Command crontab -l shows the updated file. I'm waiting to see the result.
Thanks for reminding me. Roger
What line did you add to /etc/crontab? Please paste it here. Note
that /etc/crontab uses a different format than personal crontab
files (there's an extra username field).
That command edits your personal crontab file, which has the shorter
lines (no username field is needed, because all the jobs are run as
you).
I'm still suspecting you used the wrong format in one or both files,
so it would be helpful to know what line you added to each of them,
and why you were using /etc/crontab (system-wide) if your job was
going to run as you. I'm not saying it's *wrong* to have all your system-wide and personal jobs in one place, but it's non-traditional.
On Sun, 8 Dec 2024, Greg Wooledge wrote:
What line did you add to /etc/crontab? Please paste it here. Note
that /etc/crontab uses a different format than personal crontab
files (there's an extra username field).
I added lines to /etc/crontab such as
# Watch over the NUT heartbeat at 0803 hr every day
3 8 * * * nut /usr/local/bin/heartbeat-watcher.sh > /dev/null 2>&1
# Lets have Biff bark the hours
0,1 0,12 * * * rprice /mnt/home/rprice/bark/bark.sh 12 > /dev/null 2>&1
...
0,1 11,23 * * * rprice /mnt/home/rprice/bark/bark.sh 11 > /dev/null 2>&1
That command edits your personal crontab file, which has the shorter
lines (no username field is needed, because all the jobs are run as
you).
I added a username, but crontab -e didn't complain.
On Mon, Dec 09, 2024 at 03:24:06PM +0100, Roger Price wrote:
I added lines to /etc/crontab such as
# Watch over the NUT heartbeat at 0803 hr every day
3 8 * * * nut /usr/local/bin/heartbeat-watcher.sh > /dev/null 2>&1
I added a username, but crontab -e didn't complain.
I still fear your crontab won't do what you expect it to do.
Most probably cron will just see what you intended as a user
name as part of the command:
rprice /mnt/home/rprice/bark/bark.sh 11 > /dev/null 2>&1
will run the command "rprice" on the args "/mnt..."; most of
the time this will be a "no such file or so-and-so", sometimes
it might lead to surprising results ;-)
Most probably cron will just see what you intended as a user
name as part of the command:
rprice /mnt/home/rprice/bark/bark.sh 11 > /dev/null 2>&1
will run the command "rprice" on the args "/mnt..."; most of
the time this will be a "no such file or so-and-so", sometimes
it might lead to surprising results ;-)
On Mon, 9 Dec 2024 15:59:38 +0100
<tomas@tuxteam.de> wrote:
Most probably cron will just see what you intended as a user
name as part of the command:
rprice /mnt/home/rprice/bark/bark.sh 11 > /dev/null 2>&1
will run the command "rprice" on the args "/mnt..."; most of
the time this will be a "no such file or so-and-so", sometimes
it might lead to surprising results ;-)
In which event cron will send a complaining email to the appropriate
user. Since Mr. Price hasn't mentioned any such emails, I conjecture he
is not monitoring his emails in /var/mail, and probably should be.
On Mon, Dec 09, 2024 at 15:59:38 +0100, tomas@tuxteam.de wrote:
I added a username, but crontab -e didn't complain.
I still fear your crontab won't do what you expect it to do.
Most probably cron will just see what you intended as a user
name as part of the command:
rprice /mnt/home/rprice/bark/bark.sh 11 > /dev/null 2>&1
will run the command "rprice" on the args "/mnt..."; most of
the time this will be a "no such file or so-and-so", sometimes
it might lead to surprising results ;-)
This is all correct. You (Roger) should remove the username field from
the "crontab -e" variant. Beyond that, if your command isn't working
when run from cron, you will need to read the output. So get rid of
those redirections, and let it email the output to you.
In which event cron will send a complaining email to the appropriate
user. Since Mr. Price hasn't mentioned any such emails, I
conjecture he is not monitoring his emails in /var/mail, and
probably should be.
The redirections >/dev/null 2>&1 are discarding all the output, so
there is nothing to be sent to his email.
A helpful tool here might be "cronic" (in the "cronic" package). "cronic" will swallow the output of the command it runs UNLESS that command exits
with an error code.
So one would write:
3 8 * * * cronic /usr/local/bin/hearbeat-watcher.sh
and let's imagine the shell script does "echo Everything's okay ; exit 0" once a day, then you don't get too many emails. But when it fails (echo Everything's not okay ; exit 1), then you DO get an email.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 153:23:22 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,839 |