in alma9.4 when i add or edit a crontab file in /etc/cron.d the contained commands will be executed the very next minute if applicable. in tumbleweed (20240924-3119.1) this isn’t happening. i’m thinking it’s a bug, unless cron is configured differently in opensuse/tumbleweed?
Do you have cron installed in the first place?
Probably you can use a systemd timer instead.
# status cron
+ systemctl status cron
● cron.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)
Active: active (running) since Thu 2024-09-26 09:47:55 CDT; 5 days ago
Invocation: 128da7eba3984a178ff89ed659443ed9
Main PID: 1597 (cron)
Tasks: 1
CPU: 1.179s
CGroup: /system.slice/cron.service
└─1597 /usr/sbin/cron -n
Oct 01 10:50:00 burdock CRON[636251]: (root) CMD (run-parts /etc/cron.hourly)
Oct 01 11:50:00 burdock CRON[640896]: (root) CMD (run-parts /etc/cron.hourly)
Oct 01 12:50:00 burdock CRON[645530]: (root) CMD (run-parts /etc/cron.hourly)
Oct 01 12:50:00 burdock CRON[645529]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 01 13:50:00 burdock CRON[650282]: (root) CMD (run-parts /etc/cron.hourly)
Oct 01 14:50:00 burdock CRON[655436]: (root) CMD (run-parts /etc/cron.hourly)
Oct 01 15:50:00 burdock CRON[662833]: (root) CMD (run-parts /etc/cron.hourly)
Oct 01 16:50:00 burdock CRON[667573]: (root) CMD (run-parts /etc/cron.hourly)
Oct 01 16:50:00 burdock CRON[667572]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 01 17:50:00 burdock CRON[672345]: (root) CMD (run-parts /etc/cron.hourly)
0#
$ man cron
…Cron also searches for /etc/crontab and any files in the /etc/cron.d directory…Cron examines all stored crontabs and checks each job to see if it needs to be run in the current minute…
As usual people probably want to see the facts. After all, you have a problem and ask for help. It is only fair when you provide your helpers with the same information (not only your conclusions) as you have. Thus:
ls -l /etc/cron.d
and from at least one of the files there:
cat /etc/cron.d/<filename>
It’s better in my opinion to use the crontab shell command to manage tasks, rather than manually adding them as root. Root can run crontab. It takes care of where the files go and alerts the demon that something changed.
crontab -l lists your tab file. crontab -e edits your tab file, using the editor defined in $EDITOR. Every use has their own crontab.
I do the same, but using the “system crontab” /etc/crontab and/or it’s extension /etc/crontab.d/ is documented and should work.
If one one the ways to define system wide cron runs is preferred above the others is dependent on the situation and the personal preferences of the system manager.
That is all true.
If one method doesn’t work, it’s worth it to try the other.
Yes, as by-pass. And when that works, it gives more information.
But we still wait for information asked for. Which is also more information.
I assume that when the first approach (trying other ways with the same cron definition) works, we have a case for a bug report. And I think your suggestion to do so is worthwhile. (But I am not with you when you say: “it’s better”).
The second approach may lead to finding some error in the crontab definition. Which will help the OP of course.
I cannot reproduce it. Job in /etc/cron.d is executed as scheduled.
shucks, i’d tried several times and it ignored me each time, now it works every time. maybe i was temporarily forgetting to reverse the hour and minute? don’t know. jeepers. sorry.
1 Like
Well, nice it works now.
When you would have shown something, chances are there somebody here would have seen what your mistake was. Please consider posting the computer facts next time you want help with a problem.