dcron installs a file /etc/crontab from FILESDIR containing the lines # dcron: # This is NOT the system crontab! dcron does not support a system crontab. # to get /etc/cron.{hourly|daily|weekly|montly} working with dcron run # crontab /etc/crontab # as root. But dcron apparently DOES support /etc/cron.d/*; it even installs its own prune-cronstamps in there. So I suggest a) that the code to run scripts from /etc/cron.{hourly|daily|weekly|montly} be moved to a crontab in /etc/cron.d/*. b) that /etc/crontab be replaced by a comment directing admins to /etc/cron.d as an alternative to tinkering with root's personal crontab. c) that the replacement in /etc/cron.d make use of dcron's @hourly, @daily, @weekly and @monthly specification, instead of removing the stamp file at a fixed time. This would benefit systems which aren't up all the time. d) that instead of removing the stamp files, the command in question would directly run the associated set of scripts. To do so, one would either have to duplicate the relevant portion of run-crons, or change run-crons to make that portion available in its own right, e.g. via command line arguments. If you agree with (some of) these ideas in principle, I'm willing to write an appropriate patch, or multiple patches if run-crons from cronbase should be adapted as well.
dcron leverages the existing & common run-crons script. i don't see that changing. we can move /etc/crontab to /etc/cron.d/ though.