Red Hat Bugzilla – Bug 477100
CAN'T OPEN (/etc/cron.d/<some symbolic link>): Too many levels of symbolic links
Last modified: 2009-09-25 02:36:54 EDT
Description of problem: ======================= Symbolic links in /etc/cron.d/ are not followed anymore Version-Release number of selected component (if applicable): ============================================================= cronie-1.2-4.fc10.i386 How reproducible: ================= By having symlinks in /etc/cron.d/ Steps to Reproduce: =================== 1. insert a symlink in /etc/cron.d/ 2. wait until its cron time 3. watch the cron log Actual results: =============== * The con job is not executed * You find something like this in the cron log: Dec 18 13:52:19 dns1 crond[1689]: (root) CAN'T OPEN (/etc/cron.d/radwho-clean): Too many levels of symbolic links Dec 18 13:52:19 dns1 crond[1689]: (root) CAN'T OPEN (/etc/cron.d/listproc-watchdog): Too many levels of symbolic links Dec 18 13:52:19 dns1 crond[1689]: (root) CAN'T OPEN (/etc/cron.d/spamshield): Too many levels of symbolic links Expected results: ================= Proper execution of the cron job Additional info: ================ This breakage is very critical. While it potentially breaks cron jobs that people is used to relay on, it may easily go unnoticed for long times and on servers it may lead to huge disasters.
The problem is that with inotify support cronie would have to watch all the symlinked files individually. So just simply removing the O_NOFOLLOW would not be enough. Otherwise if the symlinked file was changed the crond would not notice.
I removed O_NOFOLLOW for the meantime. At least symlinked jobs will be working, but the changes in crontab can't be watched for these files.
It seems to me to be a limitation of inotify. Not being able to watch for symlink creation and not being able to watch for changes in the file corresponding with the symlink when it is possible to do that for normal files in a directory is, in my opinion, problematic. I tested that using IN_MODIFY or IN_CLOSE_NOWRITE (and I guess IN_ACCESS could also do that) the directory is notified of those changes, but a ls also triggers an event. So not watching symlinks is certainly the best thing to do for now, but I think that it should be documented, and also that it would be nice to try to contact inotify people to add this functionality.
cronie-1.2-6.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/cronie-1.2-6.fc10
Symlinked crontabs are watched in the next version, but they need to be reloaded after change. In my opinion inotify works well and watching symlinks should be solved in user space.
cronie-1.2-7.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cronie'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11809
cronie-1.2-7.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
This problem seems to have reoccurred in Fedora 11 with cronie-1.3-2.fc11.i586
Git version didn't contain this patch. Thank for reminder. It's fixed in cronie-1.3-3.fc11.