Allan McRae <allan@xxxxxxxxxxxxx> wrote: > Surely someone can run a git bisect on this issue. It is a reasonably > new occurrence. Except that the @daily bug only trigger every 24 hours or so. A little too time consuming for git bisect, i would say. But, there is a way around this: overriding the libc time() and localtime() functions with LD_PRELOAD to trick crond into thinking time passes quicker than it actually do. libfaketime[1][2] can do this. So you can launch crond with something like this (as root): # faketime -f '+0 x30'./crond -s /tmp/systabs -c /tmp/usertabs -t /tmp/stamps -d which will make @hourly happen about every two minutess and @daily about every 48 minutes. note: using x60 and above will utterly confuse crond (Not a Bug), so don't do that. Combine with a crontab like this: @hourly ID=hourly echo "HOURLY $(date)" >> /tmp/dcron-test @daily ID=daily echo "DAILY $(date)" >> /tmp/dcron-test @weekly ID=weekly echo "WEEKLY $(date)" >> /tmp/dcron-test @monthly ID=monthly echo "MONTHLY $(date)" >> /tmp/dcron-test You can then monitor /tmp/dcron-test and see if jobs are scheduled correctly. Also the TZ environment variable can be useful (see 'info libc tz'). But, i was not able to reproduce the "@hourly run only once every two hours" problem with neither TZ=FOO-1BAR-2,N10,N350 , nor 'export TZ=:/usr/share/zoneinfo/Europe/Paris; faketime -f -60d ./crond ... -d'. So, it seems DST alone is not enough to trigger it. Presumably, it also depends upon the content of the timestamp files ? I never saw the @daily bug, personally. [1] http://www.code-wizards.com/projects/libfaketime/index.html [2] http://aur.archlinux.org/packages.php?ID=24381 -- Sent thru gmane, let's see if it works.