dcron

Since there are a lot of cron daemons available, asking why use dcron is a valid question. Some of the reasons are:

User Permissions

Users must belong to the cron group before they can create crontabs. The crontab binary is setuid as root, and can be executed by root and the cron group only.

Logging

By default, dcron logs all messages less than or equal to log level NOTICE to the system logger.

The log file can be set by /etc/conf.d/dcron using the -L option.

Unlike cronie, dcron does not send a notice to the system logger that a user's crontab has been edited.

Log Output

dcron has better log information sent to the log to help debugging. Here's an example of the date command that is being run every minute, with output sent to /tmp/cron.out: 

Oct 23 11:25:01 beandog crond: FILE /var/spool/cron/crontabs/root USER root PID 8833 date > /tmp/cron.out

You can see that the log file includes the cron file being run, the user, the PID as well as the actual command. Very useful for debugging!

Job Duplication

From the man page:

Cron jobs are not re-executed if a previous instance of them is still running. For example, if you have a crontab command sleep 70, that you request to be run every minute, crond will skip this job when it sees it is still running. So the job won't be run more frequently than once every two minutes. If you do not like this feature, you can run your commands in the background with an &.

System Clock

If the system clock changes time, and a cron job should have run, dcron will run it. From the man page:

crond automatically detects when the clock has been changed, during its per-minute scans. Backwards time-changes of an hour or less won't re-run cron jobs from the intervening period. crond will effectively sleep until it catches back up to the original time. Forwards time-changes of an hour or less (or if the computer is suspended and resumed again within an hour) will run any missed jobs exactly once. Changes greater than an hour in either direction cause crond to re-calculate when jobs should be run, and not attempt to execute any missed commands. This is effectively the same as if crond had been stopped and re-started.

For example, suppose it's 10 am, and a job is scheduled to run every day at 10:30 am. If you set the system's clock forward to 11 am, crond will immediately run the 10:30 job. If on the other hand you set the system's clock forward to noon, the 10:30 am job will be skipped until the next day. Jobs scheduled using @daily and the like work differently; see crontab(1) for details.

dcron Extensions

Special extensions that dcron supports:

Start a job once, when crond starts up 

@reboot run-first.sh

Shortcuts

You can use @daily, @hourly, etc., but when doing so, the entry must also have an identifier as well since the daemon uses timestamps to track them. 

@hourly ID=hourly-backup backups.sh

root crontab

If using dcron's native crontab, run-cron must also be manually installed into /usr/sbin as well!

While vixie-cron has a default entry for root found in /etc/crontab, dcron has something similar. The root.crontab file is the crontab entry needed that runs the hourly, daily, etc. cron jobs. In Gentoo, it's found in the documentation directory.

Here's a copy of the contents: 

# root crontab
# DO NOT EDIT THIS FILE MANUALLY! USE crontab -e INSTEAD

# man 1 crontab for acceptable formats:
#    <minute> <hour> <day> <month> <dow> <tags and command>
#    <@freq> <tags and command>

# SYSTEM DAILY/WEEKLY/... FOLDERS
@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