Arch Linux

Same here:

Mar 16 23:04:02 krom crond[11234]: mailing cron output for user root job sys-daily
Mar 16 23:04:43 krom crond[24921]: mailing cron output for user root job sys-daily

(mailed output is the same)

dcron-4.4-2

Same here:

Mar 16 23:04:02 krom crond[11234]: mailing cron output for user root job sys-daily
Mar 16 23:04:43 krom crond[24921]: mailing cron output for user root job sys-daily

(mailed output is the same)

dcron-4.4-2

I can vote for this too:

Mar 19 10:51:01 svibor crond[1242]: FILE /var/spool/cron/root USER root PID 2245
3 job sys-weekly
Mar 19 10:53:01 svibor crond[1242]: FILE /var/spool/cron/root USER root PID 1341
8 job sys-weekly

As you can see, the same weekly job is executed twice. I have to say, however, that this started only after March 14, when the DST took place. Can this be related?

BTW, has anyone seen this problem with 4.4-1? I remember there was a not-purely-Arch change, which led to 4.4-2.

I had the same problem with a new install (dcron-4.4-2, scripts in cron.daily ran twice).

I reinstalled it:
# pacman -S dcron
# /etc/rc.d/cron restart
and it seems the problem disappeared (tested only that night).

I did some testing for about a week or so, and the repetition of tasks occurs for me every other day... very strange. My loglevel was debug, but nothing unsual in the log files, except reports of (duplicate) job completion. So, I suggest, look for a several days...

You're right, the problem appeared this night again...

I'm the dcron developer and an Arch user, but didn't see this bug report until now. However I have noticed this behavior myself (others reported similar issues on the forums). dcron is in the middle of a code cleanup (which has been interrupted because of other commitments). I think it's best for me to push that through when I can, and fix this bug in the process. But I have to say, I haven't yet identified why this scheduling error is happening. It happens for some other frequencies too (@hourly). If anyone manages to narrow down the triggering conditions further, or spot a mistake in the code, I'd be glad to hear about it.

If you change your crontab lines from:
@daily ID=XX command
to:
* * * * * FREQ=1d ID=XX command

does the scheduling error still occur? I expect it will, but it'd be good to know for sure.

With this change the error still occurs on my system.

Any progress on the code cleanup? Can we further help diagnose this one?

cron.log:
Jul 20 20:01:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 6472 job backup_daily
Jul 20 20:07:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 6538 job backup_daily
Jul 20 20:17:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 6709 job backup_daily
Jul 20 20:27:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 6899 job backup_daily
Jul 20 20:37:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 7167 job backup_daily
Jul 20 20:47:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 7337 job backup_daily
Jul 20 20:57:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 7737 job backup_daily
Jul 20 21:07:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 7985 job backup_daily
Jul 20 21:12:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 8240 job sys-daily
Jul 20 21:12:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/fuxter USER fuxter PID 8241 job nds_releases
Jul 20 21:12:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/fuxter USER fuxter PID 8242 job psp_releases
Jul 20 21:17:01 fuxter-laptop crond[1957]: FILE /var/spool/cron/root USER root PID 8673 job backup_daily
Jul 20 21:23:32 fuxter-laptop crond[8858]: mailing cron output for user root job backup_daily
Jul 20 21:23:43 fuxter-laptop crond[8871]: mailing cron output for user root job backup_daily
Jul 20 21:23:51 fuxter-laptop crond[8878]: mailing cron output for user root job backup_daily
Jul 20 21:23:56 fuxter-laptop crond[8884]: mailing cron output for user root job backup_daily
Jul 20 21:24:09 fuxter-laptop crond[8891]: mailing cron output for user root job backup_daily
Jul 20 21:24:09 fuxter-laptop crond[8892]: mailing cron output for user root job backup_daily
Jul 20 21:25:05 fuxter-laptop crond[8906]: mailing cron output for user root job backup_daily

the job is:
@daily ID=backup_daily /root/backups/backup_daily.sh

* * * * * ID=backup_daily FREQ=1d /root/backups/backup_daily.sh gives the same result.

as you can guess my four months backup system has gone south ("backup_weekly" and "backup_monthly" act the same way). the only way i can use dcron is adding & sign to the end of the "command", but that's cheating, you know =)
i would like to help with testing.

pardon my russian

As well as the problem with a long-running daily being run twice, I'm also seeing my hourly skip an hour. It's happened since I first set up the system (21st June), according to the log:

Sep 16 21:50:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 30194 job sys-hourly
Sep 16 23:50:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 30948 job sys-hourly
Sep 17 01:50:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 31717 job sys-hourly
Sep 17 03:50:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 32470 job sys-hourly
Sep 17 05:50:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 790 job sys-hourly
Sep 17 07:50:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 1570 job sys-hourly
Sep 17 09:50:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 2673 job sys-hourly
Sep 17 11:02:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 3177 job sys-daily
Sep 17 11:05:01 lemlin01 crond[1484]: FILE /var/spool/cron/root USER root PID 3784 job sys-daily
Sep 17 11:05:52 lemlin01 crond[3808]: mailing cron output for user root job sys-daily

I've got this issue too, but only since 09/16/2010 according to my log...there was not any particular cron upgrade at this time though.

Here is the list of package that has been upgraded on 09/16 :

[2010-09-16 10:01] upgraded chromium (6.0.472.53-1 -> 6.0.472.59-1)
[2010-09-16 10:01] upgraded lib32-gcc-libs (4.5.1-6 -> 4.5.1-7)
[2010-09-16 10:01] upgraded gcc-libs-multilib (4.5.1-6 -> 4.5.1-7)
[2010-09-16 10:01] upgraded xulrunner (1.9.2.9-1 -> 1.9.2.10-1)
[2010-09-16 10:01] upgraded firefox (3.6.9-1 -> 3.6.10-1)
[2010-09-16 10:01] upgraded lib32-alsa-lib (1.0.23-3 -> 1.0.23-4)
[2010-09-16 10:01] upgraded lib32-alsa-plugins (1.0.23-4 -> 1.0.23-5)
[2010-09-16 10:01] upgraded lib32-pcre (8.10-2 -> 8.10-3)
[2010-09-16 10:01] upgraded lib32-zlib (1.2.5-4 -> 1.2.5-5)
[2010-09-16 10:01] upgraded lib32-glib2 (2.24.1-2 -> 2.24.1-3)
[2010-09-16 10:01] upgraded lib32-atk (1.30.0-2 -> 1.30.0-3)
[2010-09-16 10:01] upgraded lib32-attr (2.4.44-3 -> 2.4.44-4)
[2010-09-16 10:01] upgraded lib32-libpng (1.4.3-2 -> 1.4.3-3)
[2010-09-16 10:01] upgraded lib32-libxdmcp (1.0.3-3 -> 1.0.3-4)
[2010-09-16 10:01] upgraded lib32-libxau (1.0.6-1 -> 1.0.6-2)
[2010-09-16 10:01] upgraded lib32-libxcb (1.7-1 -> 1.7-2)
[2010-09-16 10:01] upgraded lib32-libx11 (1.3.5-1 -> 1.3.5-2)
[2010-09-16 10:01] upgraded lib32-libxrender (0.9.6-3 -> 0.9.6-4)
[2010-09-16 10:01] upgraded lib32-expat (2.0.1-6 -> 2.0.1-7)
[2010-09-16 10:01] upgraded lib32-freetype2 (2.4.2-2 -> 2.4.2-3)
[2010-09-16 10:01] upgraded lib32-fontconfig (2.8.0-2 -> 2.8.0-3)
[2010-09-16 10:01] upgraded lib32-pixman (0.18.4-1 -> 0.18.4-2)
[2010-09-16 10:01] upgraded lib32-cairo (1.8.10-2 -> 1.10.0-3)
[2010-09-16 10:01] upgraded lib32-openssl (1.0.0.a-5 -> 1.0.0.a-6)
[2010-09-16 10:01] upgraded lib32-curl (7.21.1-2 -> 7.21.1-3)
[2010-09-16 10:01] upgraded lib32-db (4.8.26-4 -> 4.8.26-5)
[2010-09-16 10:01] upgraded lib32-dbus-core (1.2.24-2 -> 1.4.0-2)
[2010-09-16 10:01] upgraded lib32-util-linux-ng (2.18-2 -> 2.18-3)
[2010-09-16 10:01] upgraded lib32-e2fsprogs (1.41.12-2 -> 1.41.12-3)
[2010-09-16 10:01] upgraded lib32-libogg (1.2.0-3 -> 1.2.0-4)
[2010-09-16 10:01] upgraded lib32-flac (1.2.1-6 -> 1.2.1-7)
[2010-09-16 10:01] upgraded lib32-ncurses (5.7-4 -> 5.7-5)
[2010-09-16 10:01] upgraded lib32-readline (6.1.002-2 -> 6.1.002-3)
[2010-09-16 10:01] upgraded lib32-libgpg-error (1.9-3 -> 1.9-4)
[2010-09-16 10:01] upgraded lib32-libgcrypt (1.4.6-2 -> 1.4.6-3)
[2010-09-16 10:01] upgraded lib32-gnutls (2.8.6-3 -> 2.8.6-4)
[2010-09-16 10:01] upgraded lib32-libxft (2.1.14-2 -> 2.1.14-3)
[2010-09-16 10:01] upgraded lib32-pango (1.28.1-2 -> 1.28.1-3)
[2010-09-16 10:01] upgraded lib32-sqlite3 (3.7.1-1 -> 3.7.1-2)
[2010-09-16 10:01] upgraded lib32-heimdal (1.3.3-2 -> 1.3.3-3)
[2010-09-16 10:01] upgraded lib32-libjpeg (8.0.2-2 -> 8.0.2-3)
[2010-09-16 10:01] upgraded lib32-libtiff (3.9.4-2 -> 3.9.4-3)
[2010-09-16 10:01] upgraded lib32-libcups (1.4.4-4 -> 1.4.4-5)
[2010-09-16 10:01] upgraded lib32-libxfixes (4.0.5-2 -> 4.0.5-3)
[2010-09-16 10:01] upgraded lib32-libxcursor (1.1.10-2 -> 1.1.10-3)
[2010-09-16 10:01] upgraded lib32-libxext (1.1.2-2 -> 1.1.2-3)
[2010-09-16 10:01] upgraded lib32-libxrandr (1.3.0-2 -> 1.3.0-3)
[2010-09-16 10:01] upgraded lib32-libxi (1.3.2-2 -> 1.3.2-3)
[2010-09-16 10:01] upgraded lib32-libxinerama (1.1-2 -> 1.1-3)
[2010-09-16 10:01] upgraded lib32-libxcomposite (0.4.2-2 -> 0.4.2-3)
[2010-09-16 10:01] upgraded lib32-libxdamage (1.1.3-2 -> 1.1.3-3)
[2010-09-16 10:02] upgraded lib32-gtk2 (2.20.1-3 -> 2.20.1-4)
[2010-09-16 10:02] upgraded lib32-libasyncns (0.8-4 -> 0.8-5)
[2010-09-16 10:02] upgraded lib32-libcap (2.19-2 -> 2.19-3)
[2010-09-16 10:02] upgraded lib32-libdrm (2.4.21-3 -> 2.4.21-4)
[2010-09-16 10:02] upgraded lib32-libice (1.0.6-2 -> 1.0.6-3)
[2010-09-16 10:02] upgraded lib32-libmng (1.0.10-4 -> 1.0.10-5)
[2010-09-16 10:02] upgraded lib32-libsm (1.1.1-2 -> 1.1.1-3)
[2010-09-16 10:02] upgraded lib32-libvorbis (1.3.1-3 -> 1.3.1-4)
[2010-09-16 10:02] upgraded lib32-libsndfile (1.0.21-4 -> 1.0.21-5)
[2010-09-16 10:02] upgraded lib32-libtool (2.2.10-6 -> 2.2.10-7)
[2010-09-16 10:02] upgraded lib32-libxml2 (2.7.7-2 -> 2.7.7-3)
[2010-09-16 10:02] upgraded lib32-libxt (1.0.8-2 -> 1.0.8-3)
[2010-09-16 10:02] upgraded lib32-libxmu (1.0.5-2 -> 1.0.5-3)
[2010-09-16 10:02] upgraded lib32-libxss (1.2.0-2 -> 1.2.0-3)
[2010-09-16 10:02] upgraded lib32-libxtst (1.1.0-2 -> 1.1.0-3)
[2010-09-16 10:02] upgraded lib32-libxv (1.0.5-2 -> 1.0.5-3)
[2010-09-16 10:02] upgraded lib32-libxxf86dga (1.1.1-2 -> 1.1.1-3)
[2010-09-16 10:02] upgraded lib32-libxxf86vm (1.1.0-2 -> 1.1.0-3)
[2010-09-16 10:02] upgraded lib32-mesa (7.8.2-4 -> 7.8.2-5)
[2010-09-16 10:02] upgraded lib32-nspr (4.8.6-1 -> 4.8.6-2)
[2010-09-16 10:02] upgraded lib32-nss (3.12.7-1 -> 3.12.7-2)
[2010-09-16 10:02] upgraded lib32-pulseaudio (0.9.21-12 -> 0.9.21-13)
[2010-09-16 10:02] upgraded lib32-xcb-util (0.3.6-2 -> 0.3.6-3)
[2010-09-16 10:02] upgraded libtool-multilib (2.2.10-6 -> 2.2.10-7)
[2010-09-16 10:02] upgraded ntfs-3g (2010.5.22-1 -> 2010.8.8-1)
[2010-09-16 10:02] upgraded perl-xyne-arch (2010.09.13.1-1 -> 2010.09.13.1-2)
[2010-09-16 10:02] upgraded skype (2.1.0.81-4 -> 2.1.0.81-5)
[2010-09-16 10:02] upgraded wine (1.3.2-1 -> 1.3.2-2)
[2010-09-16 10:02] upgraded xz (4.999.9beta-5 -> 4.999.9beta_174_g41bc-1)
[2010-09-16 10:38] upgraded grisbi (0.6.0-1 -> 0.6.0-2)
[2010-09-16 10:38] upgraded python-keyring (0.3-2 -> 0.4-1)
[2010-09-16 10:38] upgraded ranger (1.1.2-2 -> 1.2.0-1)
[2010-09-16 10:41] ==> upgraded, to compile the module for the new kernel version.
[2010-09-16 10:41] upgraded virtualbox_bin (3.2.8-2 -> 3.2.8-3)
[2010-09-16 13:22] upgraded kdelibs (4.5.1-1 -> 4.5.1-2)
[2010-09-16 13:24] upgraded kdelibs (4.5.1-2 -> 4.5.1-1)
[2010-09-16 13:31] upgraded kdevelop (4.0.2-1 -> 4.0.2-1)
[2010-09-16 20:26] upgraded lib32-cairo (1.10.0-3 -> 1.8.10-2)
[2010-09-16 22:19] upgraded lib32-dbus-core (1.4.0-2 -> 1.2.24-3)
[2010-09-16 22:19] upgraded mdadm (3.1.3-1 -> 3.1.4-1)
[2010-09-16 22:19] upgraded thunderbird (3.1.3-1 -> 3.1.4-1)
[2010-09-16 22:19] upgraded xfsprogs (3.1.2-1 -> 3.1.3-1)
[2010-09-16 23:43] upgraded ranger (1.2.0-1 -> 1.2.1-2)

Any news ?

Judging by the diversity of issues and since dcorn hasn't been updated since Feb., perhaps the problem is glibc, or other dcron's deps...

There where many inquiries in forums and flyspray to replace dcron with {b/f}cron. While I understand the motivation not to add new deps in the core setup, I also think that /core must not contain software with long-standing open bugs.

BTW, fcron has been moved from AUR to /community in July.

I'll try fcron then ;) Thanks

Hi guys, sorry, haven't been able to keep up with everything on my plate. I think I'll be able to fix this soon.

Jim >> thanks, let us know if you need more information ;)

Jim >> It's getting weirder....the bug has just fixed itself..exactly one week after it appeared ...(so it lasted from 09/16/2010 to 09/23/2010) ;)

I have this issue too using dcron 4.4-2 on arch x86_64.

This rule:

* * * * * ID=repo-cache FREQ=5h /home/wooptoo/bin/repo-cache

Randomly runs twice:


Oct 18 04:16:01 localhost crond[3808]: FILE /var/spool/cron/root USER root PID 14066 job repo-cache
Oct 18 04:17:01 localhost crond[3808]: FILE /var/spool/cron/root USER root PID 14069 job repo-cache

Oct 18 22:17:01 localhost crond[3808]: FILE /var/spool/cron/root USER root PID 8227 job repo-cache
Oct 18 22:22:01 localhost crond[3808]: FILE /var/spool/cron/root USER root PID 8229 job repo-cache

Oct 19 10:17:01 localhost crond[3808]: FILE /var/spool/cron/root USER root PID 14424 job repo-cache
Oct 19 10:21:01 localhost crond[3808]: FILE /var/spool/cron/root USER root PID 14426 job repo-cache

I used to have sys-hourly runned only once every two hours, but it fixed itself yesterday just as localtime switched from being UTC+2 to being UTC+1.

This is with HARDWARECLOCK="UTC" in the rc.conf, btw.

I can still see this bug and it has not been fixed. I'm considering switching to another crond since this is very annoying on large backup jobs.

Svenstaro >> Personally, I definitely switch to fcron ;)

FWIW this problem doesnt happen in Slackware so you might want to look at the sources Pat uses, especially the patches:
http://slackware.osuosl.org/slackware-13.1/source/a/dcron/

Slackware patches don't contain anything even slightly related to script scheduling.

I can see this problem on my logs too, I don't have any special jobs scheduled so I didn't notice this before the thread going on the mailing list.

This problem seems to be associated with daylight savings time change as Vincent Cappe (vcap) says. Summer time here is GMT+1 and I can see that during summer time the hourly job ran only every 2 hours.

The daily job seems to run twice every 4 days during summer time (it didn't run twice on the day the time changed) and so far not enough days have passed to be quite sure of the frequency at which the job is run twice during winter time (at first glance it seems to be every 5 days but it needs at least a couple more observations to confirm).

I can confirm this. Jobs run one hour late when DST is in effect. I noticed this when using FREQ=5h. It ran every 6 hours.

Confirmed here as well with dcron 4.4-2.
cron.hourly runs twice every hour in ~5min intervals.

@ Jim Pryor => Any chance of an update on how the code cleanup / bug fixing is coming along? It would be good to know how to pace myself with this bug. Will it be fixed in the next couple of months? Cheers :)

I have not much time to track it any further right now, but i can now trigger the double run bug reliably.

Basically, it happens when SynchronizeDir() is called while crond is waiting for a (named?) job to complete. Now, SynchronizeDir() is called every 60 iterations of the main loop and there is one iteration every ten seconds when a job is running; so a crontab entry like the following will trigger the bug every time (it only happen with @foobar and FREQ= jobs, if i am not mistaken):

* * * * * ID=donothing FREQ=20m sleep 660

if there is no bug it should run every 20 minutes; with the bug it will run about every 10 minutes.

I'm getting this on the default Arch setup:

@hourly ID=sys-hourly /usr/sbin/run-cron /etc/cron.hourly
@daily ID=sys-daily /usr/sbin/run-cron /etc/cron.daily
@weekly ID=sys-weekly /usr/sbin/run-cron /etc/cron.weekly
@monthly ID=sys-monthly /usr/sbin/run-cron /etc/cron.monthly

Does that fit with your observations?

> Does that fit with your observations?

Yes, if any of those run long enough (or a unlucky enough) to cross with a SynchronizeDir(), it will trigger the bug, afaiu.

Indeed, i discovered that accidentally while stress-testing my box; it caused updatedb to take a little longer than usual to finish, hence triggering the bug (which i had never seen previously).

Hi, thanks for the additional info. I think that will be very helpful.

As to timing, the earliest I'll have a chunk of time to give to this will be this coming weekend. The latest will be during the Christmas break. This is high on my todo list and I will try hard to make it earlier rather than later. Fixes will be pushed first to aur/dcron-git, and I will let everyone know they're available. I'll make an official release as soon as it sounds stable.

Thank you Jim; that's great news. I'll look forward to hearing more in the coming weeks :)

Did you have any success in finding time to work on this over Christmas, Jim? If not, and your schedule looks a little tight, I might have a poke around in the code myself when I get a free evening. In that case, maybe you could share with me any suspicions you might have as to the cause, and where to concentrate my efforts in the codebase?

Any progress on this?

I'd love to see this fixed as well.

In addition to cron jobs running twice, I have a reason to believe that cron.monthly doesn't run at all. Two of my systems running Arch are configured to do monthly backups via rsnapshot but it just never happens.

@Tom => There's another bug report for the problem with monthly not running: https://bugs.archlinux.org/task/19123. There's a patch on there that will fix it for you.

Also, I had some time to look at the code last night. It looks pretty tidy (except for some mixing of tabs and spaces :p), but it'll take me some time to get to grips with how it all works, as it's pretty complex. I'm hopeful I'll have something in a few days.

Thanks Paul.

I finally have a patch! I tested it over the weekend, and it does seem to have fixed the problem. Let me know if you see any side-effects, or if you continue to see any jobs run twice.

I've created an AUR package called dcron-maint (http://aur.archlinux.org/packages.php?ID=46757) containing this patch and the patch from https://bugs.archlinux.org/task/19123.

(From the negligent developer.) Thanks Paul, I'll be glad to push these into dcron-git. I hope to be able to go back and give dcron some TLC quite soon, but as we can see, work has kept me from meeting even my most pessimistic estimates about this. Still, I will push these patches into dcron-git now, and do hope to look at the rest soon.

Sounds good, Jim. I'm a bit shy of dcron-git, as I think you said you've been working on some major refactoring. I'd rather wait until 4.5 (or 5.0?) has been released and has gone through some public testing before relying on it. In the meantime, I'm keen to see a maintenance branch, and a 4.4.1 release from that branch, to prevent the patches from piling up :) Is that something you might consider?

Sure that sounds like a good plan.

Also, is it normal for @daily not to run at the same time on all systems? It's a bit weird to have logrotate rotate logs daily and not have them always start just after midnight.

Yes; I'm pretty sure this is normal. The @daily, @weekly etc... shortcuts mean "roughly this period", which is intentionally vague. In fact, I believe the code deliberately staggers those jobs to ensure they don't all run at the same time, and you'll notice there may be some drift in the time they occur over time. I believe there's a percentage margin of error that is considered acceptable for those tasks. If you need a job to run at midnight, I think you'd better user the traditional cron notation with the stars, which is enforced much more strictly.

I'll be releasing dcron v4.5 shortly, which I think should fix this issue. There are multiple causes behind the issues reported here. The issue Paul identified and two others will be fixed in 4.5. I'll hold off on pushing the refactoring I've done until a later release.

Excellent news; thanks Jim :)

Hello. No, putting "* * * * * ID=sys-daily FREQ=1d command..." instead of "@daily ID=sys-daily command..." has *not* solved the issue for me (although I first though it worked). Thanks

Hi Marc, those two specifications are handled equivalently, so I wouldn't expect to see any difference between them. Are you using dcron-4.5-2 from [testing] (or a fresh build of dcron-git)? If you are, I'll ask you to run `sudo /etc/rc.d/dcron restart` (even if you've already done it once; I saw an issue myself that only showed up on the first restart after installing). And if problems persist, please email me details offline at <profjim@jimpryor.net>. We'll figure out what's going on and summarize here for others.

Jim, I am using the dcron-4.4-2 version.

OK, I believe the bug reported here is fixed in dcron v4.5.