/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.
the 'exit 0' did not help, root still got mail today..
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..
*** Bug 10409 has been marked as a duplicate of this bug. ***
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 .
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.
thanks a bunch.
*** Bug 10675 has been marked as a duplicate of this bug. ***
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...
Reopening by request posted by Andreas Vinsander <andreas.vinsander at teligent dot se> to gentoo-dev@
Re-assigning to cron-bugs.
I've been seeing the above mentioned problem here as well.
*** Bug 81222 has been marked as a duplicate of this bug. ***
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.
>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
> 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.
*** Bug 82268 has been marked as a duplicate of this bug. ***
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...
I've added 0.3.2. Please test and reopen if necessary.
Created attachment 54551 [details, diff] 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.
Created attachment 54552 [details, diff] 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.
Please pardon the double-submit. 'Twas worlds of unintentional.
