2

I'm seeing strange cron behavior which I'm not sure how to debug and fix.

It ignores changes to /etc/crontab until restarted, e.g. I edit /etc/crontab adding

* * * * * root echo 'weee' > /tmp/stupidcron

to it. Then:

root@linux-plba:~# sleep 270 && ls /tmp/stupidcron ls: cannot access /tmp/stupidcron: No such file or directory

Anything added with crontab utility works.

If I restart cron, the change is picked up, but any latter changes are not until the next restart.

I have root mail redirected to my inbox, and there's nothing of interest there. I also don't see anything in syslog.

Closest thing to this I've found is this old thread in FreeBSD mailing list:

http://lists.freebsd.org/pipermail/freebsd-questions/2010-September/221179.html

The cron is Vixie cron 4.1-194.209.1 x86-64

Probably, someone have seen such behavior or knows how to further debug/fix it?

P.S. I did read the community wiki on it: Why is my crontab not working, and how can I troubleshoot it? and I believe this case is not covered there.

Community
  • 1
Roman Grazhdan
  • 334
  • 3
  • 15
  • Which OS/Distro are you using ? – user9517 Aug 28 '14 at 15:40
  • It's SLES 11.3, but it's sort of a lab machine and it's not eligible for tech support – Roman Grazhdan Aug 28 '14 at 16:17
  • Maybe try tracing the `cron` process, and see if it's calling `stat()` on `/etc/crontab` every minute like it should. Perhaps it's getting an error for some reason. – Barmar Aug 28 '14 at 19:28
  • `strace -q -estat` says it does – Roman Grazhdan Aug 29 '14 at 06:13
  • The curious thing is `read` doesn't follow (unlike when I edit user's crontab) – Roman Grazhdan Aug 29 '14 at 06:20
  • I know one bug with cron in SLES: If you use a symbolic link to your crontab file (like those `cron.daily` files), and you change the crontab file, cron does not realize and still executes the old command. That also seems to indicate that cron actually caches the commands to execute. – U. Windl Apr 19 '21 at 09:52

2 Answers2

1

OK, it seems like this question has no actual answer.

My colleague decided to downgrade cron and see what happens, and it worked just fine.

So he looked through spec files in SRPMs for older and newer versions and it seems to be one of patches breaking cron:

* Wed Aug 6 2014 tchvatal@suse.com - Fix cron man page being ambiguous bnc#853010: * bnc#853010-manpage-ambiguous.patch - Fix wrong mtime when reruning cron scripts bnc#879734: * bnc#879734-directory-mtime.patch

Since the trace shows cron does stat the file and the struct it gets is correct, it's the cron issue, not something misconfigured/permissions problem etc.

Roman Grazhdan
  • 334
  • 3
  • 15
-2

When you use crontab -e (the standard way of adding cron jobs) you may have noticed that you are editing a temporary text file. After you exit the crontabs are installed automatically.Crontab will create one file for each user in /var/spool/cron/crontabs. And the cron daemon of course looks for /etc/crontab too.

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.ZRmGzQ/crontab installed on Mon May 12 07:50:40 2014)

This is the header of one user file in /var/spool/cron/crontabs. It implies that editing the file will not do the job. Also /tmp/crontab.ZRmGzQ/crontab denotes the temporary file used by crontab -e at the last update.

sysadmin@omg:~$ crontab -l > tmp-cron.txt
sysadmin@omg:~$ echo '*/1 * * * * echo "APOEL ULTRAS" >> /tmp/stupidcron' >> tmp-cron.txt
sysadmin@omg:~$ crontab tmp-cron.txt
sysadmin@omg:~$ sleep 150 && cat /tmp/stupidcron
APOEL ULTRAS
APOEL ULTRAS

Here I am exporting my current crontabs to a temporary file tmp-cron.txt, adding a crontab and installing the file again. Works fine.

So basically the crontab in your case is not working because it has not been installed.

Just be careful when you install a new text file you overwrite the old. Backup your files before playing around.

Louis Papaloizou
  • 453
  • 3
  • 7
  • It's true, but, from `man cron`: `Additionally, cron checks each minute to see if its spool directory's modtime (or the modtime on /etc/crontab) has changed, and if it has, cron will then examine the modtime on all crontabs and reload those which have changed. Thus cron need not be restarted whenever a crontab file is modified. Note that the Crontab(1) command updates the modtime of the spool directory whenever it changes a crontab.` mtime of /etc/crontab does change when I edit it. – Roman Grazhdan Aug 28 '14 at 16:40
  • I think this is complete rubbish. On all the systems I have to hand, vixie-cron checks the user crontabs and the system crontabs every minute (the man page even says this) for changes. – user9517 Aug 28 '14 at 16:56
  • Furthermore, the `crontab` command can only be used with user-specific crontabs. There's nothing analogous for `/etc/crontab`, you have to edit it directly, and that's specifically what the question is about. – Barmar Aug 28 '14 at 19:26
  • Actually now that I revise this, it is complete rubbish indeed. I thought I replicated the problem, apparently I didn't. – Louis Papaloizou Aug 28 '14 at 19:33