Vixie-cron will not load any scripts from /etc/cron.d/ that have the execute bit set. In these cases, it complains "(*system*) BAD FILE MODE (/etc/cron.d/<script>)". /usr/sbin/run-crons, provided by cronbase, skips any scripts that do not have the execute bit set. This causes problems because vixie-cron calls run-crons for processing /etc/cron.{hourly,daily,weekly}/*. So valid file permissions for vixie-cron cause those scripts to not execute if they are symlinked to scripts in /etc/cron.d/. Reproducible: Always Steps to Reproduce: A. 1. Create script in /etc/cron.d/ with 644 root:root permissions. 2. Symlink script to /etc/cron.hourly/ 3. (Re)Start vixie-cron. B. 1. chmod 744 /etc/cron.d/testscript 2. Restart vixie-cron Actual Results: A. Script does not run, no errors logged. B. Vixie-cron logs errors about bad file mode, script does not run. Expected Results: Scripts should load and run. Either vixie-cron should allow execute permission on /etc/cron.d/*, or run-crons should use a subshell to run scripts without +x set. Lines 94-98 of /usr/sbin/run-crons, as provided by cronbase: for SCRIPT in $CRONDIR/* ; do if [[ -x $SCRIPT && ! -d $SCRIPT ]]; then $SCRIPT fi
Reading https://bugzilla.redhat.com/show_bug.cgi?id=143191, it looks like this misbehavior is considered a security feature on cron's part. So perhaps the fix needs to go into cronbase?
AFAICT cron.d is used to provide files that are in crontab format (with time specification and actions) while cron.{hourly,daily,weekly,monthly} provides full scripts to exec. So the problem is entirely a matter of "you shouldn't be symlinking from cron.d to cron.hourly"...
Ah.. hmm. OK. I suppose it was silly of me to assume that it was of the same purpose as /etc/init.d/. However, searching the Web shows that it's a fairly common perception of the purpose of this directory.
OK, I looked up RedHat's documentation, and Flameeyes is correct. Files in /etc/cron.d/ take the same format as /etc/crontab, and are meant for scheduling tasks at intervals other than daily/weekly/monthly.
