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

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
-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
  • 463