8506 2002-09-28 08:42 0000 /usr/sbin/run-crons returns non-zero value 2005-03-26 15:57:37 0000 1 1 1 Unclassified Gentoo Linux Applications 1.4_rc1 x86 Linux RESOLVED FIXED P4 trivial --- 1 captainjay@gmx.net cron-bugs@gentoo.org andreas@vinsander.se ceder@lysator.liu.se gentoo@divinehawk.com h3y@esaurito.net henrik@brixandersen.dk j_r_fonseca@yahoo.co.uk lilwyrm@gmail.com tpeland@tkukoulu.fi captainjay@gmx.net 2002-09-28 08:42:50 0000 /usr/sbin/run-crons from sys-apps/cronbase returns a non-zero value, so root gets mail from Cron Daemon containing the following line every day: find: /var/spool/cron/lastrun/cron.hourly: No such file or directory 'exit 0' after the last line of this script may help, but probably there is a better solution. captainjay@gmx.net 2002-09-29 16:15:06 0000 the 'exit 0' did not help, root still got mail today.. woodchip@gentoo.org 2002-10-02 07:35:40 0000 are you still having this and do you know if this is a bonified bug, and/or have a fix/further suggestion? i have to admit i dont use the run-crons and cronbase extra stuff since i fine fcron much easier for my needs ;-) lemme know.. vapier@gentoo.org 2002-11-07 20:11:45 0000 *** Bug 10409 has been marked as a duplicate of this bug. *** j_r_fonseca@yahoo.co.uk 2002-11-08 04:06:27 0000 Sorry for the duplicate. I made a quick search before submiting and saw this bug summary but I didn't though it was the same one. Anyway, consider the fix I suggested on #10409 . j_r_fonseca@yahoo.co.uk 2002-11-11 11:07:48 0000 The solution I suggested on bug #10409, of replacing find /var/spool/cron/lastrun/cron.$BASE $TIME -exec rm {} \; by find /var/spool/cron/lastrun/ -name cron.$BASE $TIME -exec rm {} \; effectively solves this problem. Please apply it on portage. woodchip@gentoo.org 2002-11-12 23:11:17 0000 thanks a bunch. vapier@gentoo.org 2002-11-13 15:31:47 0000 *** Bug 10675 has been marked as a duplicate of this bug. *** andreas@vinsander.se 2004-11-02 01:25:26 0000 I want to revive this one... We are sometimes seeing the same behaviour on some of our systems running sys-apps/vixie-cron-3.0.1-r4 and sys-apps/cronbase-0.3.1. The problem seems to be that on each hour the file cron.hourly is removed by /etc/crontab. If it doesn't exist or if it is older than 65 minutes, then /usr/sbin/run-crons will activate hourly jobs (/usr/sbin/run-crons is started once each 10 minutes by /etc/crontab). There is a race condition here. If run-crons finds a cron-hourly file, but it is removed before run-crons finds out if it is more than 65 minutes old, then the message regarding /var/spool/cron/lastrun/cron.hourly will be mailed out. A completely harmless bug... but can be annoying if it happens a lot. Sorry for not giving a solution... hope somebody can use the diagnose though... henrik@brixandersen.dk 2004-11-02 06:44:36 0000 Reopening by request posted by Andreas Vinsander <andreas.vinsander at teligent dot se> to gentoo-dev@ henrik@brixandersen.dk 2004-11-02 06:45:45 0000 Re-assigning to cron-bugs. henrik@brixandersen.dk 2004-11-02 06:47:14 0000 I've been seeing the above mentioned problem here as well. ka0ttic@gentoo.org 2005-02-08 05:40:44 0000 *** Bug 81222 has been marked as a duplicate of this bug. *** ka0ttic@gentoo.org 2005-02-08 06:15:27 0000 Tero, btw doing find ... rm -f won't work, as find still returns an error value as well as displaying the No such file or directory message. We can either do something icky like find ... &>/dev/null || true (like I said icky) or try (if possible) to arrange the times so they won't conflict. That, of course, would go out the window as soon as a user modified it though. tpeland@tkukoulu.fi 2005-02-08 23:24:02 0000 >doing find ... rm -f won't work, as find still returns an error value as well as displaying the No such file or directory message. Not true. Only cases that show error value are: rm without -f find with nonexisting base directory "/bin/rm -f nonexisting" would give no error message and no error value ka0ttic@gentoo.org 2005-02-09 02:38:03 0000 > Not true. > Only cases that show error value are: > rm without -f > find with nonexisting base directory > "/bin/rm -f nonexisting" would give no error message and no error value Yes, however, with the race condition, it exists when find starts but not when it gets to the part where it tries to rm -f it. That's a find error, not a rm error. If you really want to test it, open two terminals next to each other and as simultaneously as possible, run "find /usr/portage -name '*.ebuild' -exec rm -f {} \;" in each. Of course, you can use something else besides the portage tree, but it's got to be something with a lot of files in order to reproduce the race condition. I just used the tree as it's something easily recoverable. ka0ttic@gentoo.org 2005-02-17 08:04:13 0000 *** Bug 82268 has been marked as a duplicate of this bug. *** loci@locimotive.de 2005-03-06 09:14:10 0000 what about changing find ${LOCKDIR} -name cron.$BASE $TIME -exec rm {} \; to find ${LOCKDIR} -name cron.$BASE $TIME -exec rm {} 2> /dev/null \; I see no place where an error report could be useful... and it's only the rm-error which is eliminated. correct me if i'm wrong... ka0ttic@gentoo.org 2005-03-09 04:51:25 0000 I've added 0.3.2. Please test and reopen if necessary. lilwyrm@gmail.com 2005-03-26 15:53:53 0000 Created an attachment (id=54551) patch to the run-crons script I've written a way to work around the race condition in find that's a li'l less icky than "...&>/dev/null || true". I tested it out with your suggestion of removing the portage tree, and it works swimmingly with no extraneous output. (simultaneously, from two consoles) $ find portage/ -type f | xargs -l rm -f $ echo $? 0 Submitted for your approval, and I'll leave it to you to add whatever changelog entry you find appropriate. lilwyrm@gmail.com 2005-03-26 15:54:05 0000 Created an attachment (id=54552) patch to the run-crons script I've written a way to work around the race condition in find that's a li'l less icky than "...&>/dev/null || true". I tested it out with your suggestion of removing the portage tree, and it works swimmingly with no extraneous output. (simultaneously, from two consoles) $ find portage/ -type f | xargs -l rm -f $ echo $? 0 Submitted for your approval, and I'll leave it to you to add whatever changelog entry you find appropriate. lilwyrm@gmail.com 2005-03-26 15:57:37 0000 Please pardon the double-submit. 'Twas worlds of unintentional. 54551 2005-03-26 15:53 0000 patch to the run-crons script run-crons-0.3.3.diff text/plain LS0tIHJ1bi1jcm9ucy0wLjMuMgorKysgcnVuLWNyb25zLTAuMy4zCkBAIC04NCw3ICs4NCw3IEBA CiAJCSM+PSAzMSBkYXlzLCA1IG1pbiAtPT4gKzQ0NjQ1IG1pbgogCQlUSU1FPSItY21pbiArNDQ2 NDUiIDs7CiAJZXNhYwotICAgICAgICBmaW5kICR7TE9DS0RJUn0gLW5hbWUgY3Jvbi4kQkFTRSAk VElNRSAtZXhlYyBybSB7fSBcOyAmPi9kZXYvbnVsbCB8fCB0cnVlCisgICAgICAgIGZpbmQgJHtM T0NLRElSfSAtbmFtZSBjcm9uLiRCQVNFICRUSU1FIC10eXBlIGYgfCB4YXJncyBybSAtZgogICAg IGZpCiAKICAgICAjIGlmIHRoZXJlIGlzIG5vIHRvdWNoIGZpbGUsIG1ha2Ugb25lIHRoZW4gcnVu IHRoZSBzY3JpcHRzCkBAIC0xMDQsNCArMTA0LDQgQEAKIAogIyBDbGVhbiBvdXQgYm9ndXMgY3Jv bi4kQkFTRSBmaWxlcyB3aXRoIGZ1dHVyZSB0aW1lcwogdG91Y2ggJHtMT0NLRElSfQotZmluZCAk e0xPQ0tESVJ9IC1uZXdlciAke0xPQ0tESVJ9IC1leGVjIC9iaW4vcm0gLWYge30gXDsgJj4vZGV2 L251bGwgfHwgdHJ1ZQorZmluZCAke0xPQ0tESVJ9IC1uZXdlciAke0xPQ0tESVJ9IC1leGVjIC9i aW4vcm0gLWYge30gXDsK 54552 2005-03-26 15:54 0000 patch to the run-crons script run-crons-0.3.3.diff text/plain LS0tIHJ1bi1jcm9ucy0wLjMuMgorKysgcnVuLWNyb25zLTAuMy4zCkBAIC04NCw3ICs4NCw3IEBA CiAJCSM+PSAzMSBkYXlzLCA1IG1pbiAtPT4gKzQ0NjQ1IG1pbgogCQlUSU1FPSItY21pbiArNDQ2 NDUiIDs7CiAJZXNhYwotICAgICAgICBmaW5kICR7TE9DS0RJUn0gLW5hbWUgY3Jvbi4kQkFTRSAk VElNRSAtZXhlYyBybSB7fSBcOyAmPi9kZXYvbnVsbCB8fCB0cnVlCisgICAgICAgIGZpbmQgJHtM T0NLRElSfSAtbmFtZSBjcm9uLiRCQVNFICRUSU1FIC10eXBlIGYgfCB4YXJncyBybSAtZgogICAg IGZpCiAKICAgICAjIGlmIHRoZXJlIGlzIG5vIHRvdWNoIGZpbGUsIG1ha2Ugb25lIHRoZW4gcnVu IHRoZSBzY3JpcHRzCkBAIC0xMDQsNCArMTA0LDQgQEAKIAogIyBDbGVhbiBvdXQgYm9ndXMgY3Jv bi4kQkFTRSBmaWxlcyB3aXRoIGZ1dHVyZSB0aW1lcwogdG91Y2ggJHtMT0NLRElSfQotZmluZCAk e0xPQ0tESVJ9IC1uZXdlciAke0xPQ0tESVJ9IC1leGVjIC9iaW4vcm0gLWYge30gXDsgJj4vZGV2 L251bGwgfHwgdHJ1ZQorZmluZCAke0xPQ0tESVJ9IC1uZXdlciAke0xPQ0tESVJ9IC1leGVjIC9i aW4vcm0gLWYge30gXDsK