Running 9.3. For some reason unknown to me, the cron.daily scripts are running later and later in the day. They seem to be shifting approx 15 minutes later each day and this behavior appears to have started after I updated to 9.3 from 9.2. The time looks to be calculated somehow in /usr/lib/cron/run-crons, the section of the script that does it is here RUN="" for CRONDIR in /etc/cron.{hourly,daily,weekly,monthly} ; do test -d $CRONDIR || continue BASE=${CRONDIR##*/} TIME_EXT=${BASE##cron.} test -e $SPOOL/$BASE && { case $BASE in cron.hourly) TIME="-cmin +60 -or -cmin 60" ;; cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;; cron.monthly) NOW=`date +%s` LASTMONTH=`date -d "last month" +%s` DIFF=`expr '(' $NOW - $LASTMONTH ')' / 86400` TIME="-ctime +$DIFF" ;; esac # remove all lock files for scripts that are due to run eval find $SPOOL/$BASE $TIME | \ xargs --no-run-if-empty rm } I've stared and stared at it but can't see where it is bumping it by this weird 15 minute increase each day. Anyone have any clues? And, how do I get cron.daily back to running at a reasonable time, like 4am or 5am in the morning? Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-20a-default x86_64
Op zaterdag 7 mei 2005 17:12, schreef Scott Leighton:
test -e $SPOOL/$BASE && { case $BASE in cron.hourly) TIME="-cmin +60 -or -cmin 60" ;; cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;; cron.monthly) NOW=`date +%s` LASTMONTH=`date -d "last month" +%s` DIFF=`expr '(' $NOW - $LASTMONTH ')' / 86400` TIME="-ctime +$DIFF" ;; esac # remove all lock files for scripts that are due to run eval find $SPOOL/$BASE $TIME | \ xargs --no-run-if-empty rm }
I've stared and stared at it but can't see where it is bumping it by this weird 15 minute increase each day. Anyone have any clues?
It's already fixed for then next suse release ;) Change:
cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;;
to cron.daily) TIME="-cmin +1440 -or -cmin 1440" ;; cron.weekly) TIME="-cmin +10080 -or -cmin 10080" ;;
And, how do I get cron.daily back to running at a reasonable time, like 4am or 5am in the morning?
touch "with your timestamp" /var/spool/cron/lastrun/cron.daily -- Richard Bos Without a home the journey is endless
On Saturday 07 May 2005 8:17 am, Richard Bos wrote:
It's already fixed for then next suse release ;)
Change:
cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;;
to
cron.daily) TIME="-cmin +1440 -or -cmin 1440" ;; cron.weekly) TIME="-cmin +10080 -or -cmin 10080" ;;
And, how do I get cron.daily back to running at a reasonable time, like 4am or 5am in the morning?
touch "with your timestamp" /var/spool/cron/lastrun/cron.daily
Thanks! That solved it. I did have to use the -t switch on touch, e.g., touch -t 200505070500 cron.daily Worked like a charm. Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-20a-default x86_64
On Saturday 07 May 2005 17:39, Scott Leighton wrote:
And, how do I get cron.daily back to running at a reasonable time, like 4am or 5am in the morning?
touch "with your timestamp" /var/spool/cron/lastrun/cron.daily
Thanks! That solved it. I did have to use the -t switch on touch, e.g.,
touch -t 200505070500 cron.daily
Worked like a charm.
I don't think so. That unfortunately doesn't seem to set the correct time stamp. Try find /var/spool/cron/lastrun -name cron.daily -printf "%c\n" The timestamp you see there is the one that will control when it's run. So far, the only way I've found to do it correctly is to do at 5am
rm /var/spool/cron/lastrun/cron.daily touch /var/spool/cron/lastrun/cron.daily <ctrl-D>
Make sure atd is running (rcatd start)
Anders, On Saturday 07 May 2005 08:51, Anders Johansson wrote:
On Saturday 07 May 2005 17:39, Scott Leighton wrote: ...
touch -t 200505070500 cron.daily
Worked like a charm.
I don't think so. That unfortunately doesn't seem to set the correct time stamp. Try
find /var/spool/cron/lastrun -name cron.daily -printf "%c\n"
I'm fond of the "stat" command for this sort of thing.
The timestamp you see there is the one that will control when it's run.
So far, the only way I've found to do it correctly is to do
at 5am
rm /var/spool/cron/lastrun/cron.daily touch /var/spool/cron/lastrun/cron.daily <ctrl-D>
This, of course, hinges on your definition of "correctly." I'm sure this will make some cringe (myself included), but I did it and it seemed not to cause anything catastrophic: % rm /var/spool/cron/lastrun/cron.daily; \ date 050604002005.00; \ touch /var/spool/cron/lastrun/cron.daily; \ date 050610252005.00 Fri May 6 04:00:00 PDT 2005 Fri May 6 10:25:00 PDT 2005 Of course, you have to choose the second date to correspond with the instant at which you plan to hit return and launch these commands. It does have the desired effect: % stat \ -c $'Access: %x\nModify: %y\nChange: %z\n' \ /var/spool/cron/lastrun/cron.daily Access: 2005-05-06 04:00:00.017178085 -0700 Modify: 2005-05-06 04:00:00.017178085 -0700 Change: 2005-05-06 04:00:00.017178085 -0700 Randall Schulz
On Friday 06 May 2005 19:33, Randall R Schulz wrote:
I'm fond of the "stat" command for this sort of thing.
Yeah, but using find is better in this case because it is actually find doing the job in run-crons, so we know for sure that it is the same thing we're talking about.
This, of course, hinges on your definition of "correctly." I'm sure this will make some cringe (myself included), but I did it and it seemed not to cause anything catastrophic:
% rm /var/spool/cron/lastrun/cron.daily; \ date 050604002005.00; \ touch /var/spool/cron/lastrun/cron.daily; \ date 050610252005.00 Fri May 6 04:00:00 PDT 2005 Fri May 6 10:25:00 PDT 2005
Of course, you have to choose the second date to correspond with the instant at which you plan to hit return and launch these commands.
Yeah, I prefer not to change system time if I don't absolutely have to. The command doesn't have to be run until just before the run, and atd is perfect for things like that.
On Sat, 2005-05-07 at 17:51 +0200, Anders Johansson wrote:
On Saturday 07 May 2005 17:39, Scott Leighton wrote:
And, how do I get cron.daily back to running at a reasonable time, like 4am or 5am in the morning?
touch "with your timestamp" /var/spool/cron/lastrun/cron.daily
Thanks! That solved it. I did have to use the -t switch on touch, e.g.,
touch -t 200505070500 cron.daily
Worked like a charm.
I don't think so. That unfortunately doesn't seem to set the correct time stamp. Try
find /var/spool/cron/lastrun -name cron.daily -printf "%c\n"
The timestamp you see there is the one that will control when it's run.
So far, the only way I've found to do it correctly is to do
at 5am
rm /var/spool/cron/lastrun/cron.daily touch /var/spool/cron/lastrun/cron.daily <ctrl-D>
Make sure atd is running (rcatd start)
No need to remove the file only touch it. From man touch... NAME touch - change file timestamps SYNOPSIS touch [OPTION]... FILE... DESCRIPTION Update the access and modification times of each FILE to the current time. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Saturday 07 May 2005 18:16, Ken Schneider wrote:
No need to remove the file only touch it.
Fair enough, one line less. I just assumed that since touch -t didn't change the correct timestamp, just running touch wouldn't do it either, but I just tested it and you are right, just running touch will do it. Actually, I overlooked that if you do what I said, you'd skip one night's daily run. So instead at 4.59am
rm /var/spool/cron/lastrun/cron.daily <ctrl-D>
should make it run at 5am
On Saturday 07 May 2005 8:51 am, Anders Johansson wrote:
On Saturday 07 May 2005 17:39, Scott Leighton wrote:
And, how do I get cron.daily back to running at a reasonable time, like 4am or 5am in the morning?
touch "with your timestamp" /var/spool/cron/lastrun/cron.daily
Thanks! That solved it. I did have to use the -t switch on touch, e.g.,
touch -t 200505070500 cron.daily
Worked like a charm.
I don't think so. That unfortunately doesn't seem to set the correct time stamp. Try
find /var/spool/cron/lastrun -name cron.daily -printf "%c\n"
The timestamp you see there is the one that will control when it's run.
So far, the only way I've found to do it correctly is to do
at 5am
rm /var/spool/cron/lastrun/cron.daily touch /var/spool/cron/lastrun/cron.daily <ctrl-D>
Make sure atd is running (rcatd start)
You are correct, all I changed was the mtime and the cron script appears to be interested only in the ctime. A bit of googling seems to indicate that it is not possible to change the ctime, the only way is the one you mention above, delete the file and create a new one. I don't think I like this new way of handling crontabs. Seems it is needlessly complex to me. Thanks for pointing out the issue, I wouldn't have noticed until tomorrow that the original solution failed! Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-20a-default x86_64
Op zaterdag 7 mei 2005 17:39, schreef Scott Leighton:
On Saturday 07 May 2005 8:17 am, Richard Bos wrote:
It's already fixed for then next suse release ;)
Change:
cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;;
to
cron.daily) TIME="-cmin +1440 -or -cmin 1440" ;; cron.weekly) TIME="-cmin +10080 -or -cmin 10080" ;;
And, how do I get cron.daily back to running at a reasonable time, like 4am or 5am in the morning?
touch "with your timestamp" /var/spool/cron/lastrun/cron.daily
Thanks! That solved it. I did have to use the -t switch on touch, e.g.,
touch -t 200505070500 cron.daily
Worked like a charm.
Scott
To finish off, I added a summary of this discussion to the wiki dedicated to suse. You can find the page at: http://www.susewiki.org/index.php?title=Schedule_cron_daily You can come there using: http://www.susewiki.org/index.php?title=Category:Howto or http://www.susewiki.org/index.php?title=Category:FAQ Please update the article if you find mistakes, and the like. -- Richard Bos Without a home the journey is endless
On Sat, 2005-05-07 at 17:17 +0200, Richard Bos wrote:
Op zaterdag 7 mei 2005 17:12, schreef Scott Leighton:
test -e $SPOOL/$BASE && { case $BASE in cron.hourly) TIME="-cmin +60 -or -cmin 60" ;; cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;; cron.monthly) NOW=`date +%s` LASTMONTH=`date -d "last month" +%s` DIFF=`expr '(' $NOW - $LASTMONTH ')' / 86400` TIME="-ctime +$DIFF" ;; esac # remove all lock files for scripts that are due to run eval find $SPOOL/$BASE $TIME | \ xargs --no-run-if-empty rm }
I've stared and stared at it but can't see where it is bumping it by this weird 15 minute increase each day. Anyone have any clues?
It's already fixed for then next suse release ;)
Change:
cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;;
to
cron.daily) TIME="-cmin +1440 -or -cmin 1440" ;; cron.weekly) TIME="-cmin +10080 -or -cmin 10080" ;;
And, how do I get cron.daily back to running at a reasonable time, like 4am or 5am in the morning?
touch "with your timestamp" /var/spool/cron/lastrun/cron.daily What ever happened to using the system clock to schedule cron jobs? Seemed to work correctly for how many years? Now you schedule based on how long ago a file was created which is rather short sighted to me. Like I have said in the past If it aint broke, don't fix it (break it)
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Sat, May 07, 2005 at 12:12:53PM -0400, Ken Schneider wrote:
What ever happened to using the system clock to schedule cron jobs? Seemed to work correctly for how many years? Now you schedule based on how long ago a file was created which is rather short sighted to me. Like I have said in the past If it aint broke, don't fix it (break it)
My /etc/crontab prior to upgrading to 9.3 had these lines in it: 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 04 0 * * * root rm -f /var/spool/cron/lastrun/cron.daily 29 1 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 44 1 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly I added them back into the 9.3 one and now my cron jobs run when I want them to. I wonder why that was removed in 9.3? -- San Francisco, CA
On Sat, 2005-05-07 at 09:38 -0700, Michael Nelson wrote:
On Sat, May 07, 2005 at 12:12:53PM -0400, Ken Schneider wrote:
What ever happened to using the system clock to schedule cron jobs? Seemed to work correctly for how many years? Now you schedule based on how long ago a file was created which is rather short sighted to me. Like I have said in the past If it aint broke, don't fix it (break it)
My /etc/crontab prior to upgrading to 9.3 had these lines in it:
59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 04 0 * * * root rm -f /var/spool/cron/lastrun/cron.daily 29 1 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 44 1 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly
I added them back into the 9.3 one and now my cron jobs run when I want them to.
I wonder why that was removed in 9.3? It was actually changed in 9.2, I think even earlier as I see a run-crons file in my 9.0 system as well. I guess it has come down to, if it ain't broke let's see if we can break it.
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Ken Schneider wrote:
It was actually changed in 9.2, I think even earlier as I see a run-crons file in my 9.0 system as well.
That may be. I have upgraded the system a bunch of times since initially installing SuSE at version 7.something. ;-) Michael
Ken, On Saturday 07 May 2005 09:12, Ken Schneider wrote:
...
What ever happened to using the system clock to schedule cron jobs? Seemed to work correctly for how many years? Now you schedule based on how long ago a file was created which is rather short sighted to me.
I believe the shortsightedness is your own. Many users don't leave their systems running 24/7 and if the daily processing scheduling was done in the manner you suggest, it would simply be skipped if the system did not happen to be up at the selected time.
Like I have said in the past If it aint broke, don't fix it (break it)
More like "If you don't like it, lump it" or, perhaps, "My way or the highway."
-- Ken Schneider
Randall Schulz
On Sat, 2005-05-07 at 10:08 -0700, Randall R Schulz wrote:
Ken,
On Saturday 07 May 2005 09:12, Ken Schneider wrote:
...
What ever happened to using the system clock to schedule cron jobs? Seemed to work correctly for how many years? Now you schedule based on how long ago a file was created which is rather short sighted to me.
I believe the shortsightedness is your own.
Many users don't leave their systems running 24/7 and if the daily processing scheduling was done in the manner you suggest, it would simply be skipped if the system did not happen to be up at the selected time. This is true. What is the possibility of time creep on the files so that after a while the time at which they run starts becoming later in the day? Or is that something that actually runs in cron from the system clock. Also what about the people that just can't seem to set their clocks properly?
Like I have said in the past If it ain't broke, don't fix it (break it)
More like "If you don't like it, lump it" or, perhaps, "My way or the highway." I see no need for you to get offensive. I merely point out that something has worked well for many years, they change it and now people have problems. Perhaps better testing is in order then. And better documentation.
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Ken, On Saturday 07 May 2005 12:19, Ken Schneider wrote:
On Sat, 2005-05-07 at 10:08 -0700, Randall R Schulz wrote:
Ken,
On Saturday 07 May 2005 09:12, Ken Schneider wrote:
...
What ever happened to using the system clock to schedule cron jobs? Seemed to work correctly for how many years? Now you schedule based on how long ago a file was created which is rather short sighted to me.
I believe the shortsightedness is your own.
Many users don't leave their systems running 24/7 and if the daily processing scheduling was done in the manner you suggest, it would simply be skipped if the system did not happen to be up at the selected time.
This is true. What is the possibility of time creep on the files so that after a while the time at which they run starts becoming later in the day? Or is that something that actually runs in cron from the system clock. Also what about the people that just can't seem to set their clocks properly?
What about them? The magnitude of the discrepancy between the sanctioned time standard and the clock on any given machine (which is never zero) is not the issue. If the system is running 24 hours a day, daily cron jobs will get run even if they're scheduled using the naive means you suggest. But if the system is not up 24 hours per day, then they may not. In fact, if you pick an overnight time for the daily cron jobs and the system is only running during, say, business hours, then the daily cron will probably never get run. And I don't understand what you're saying about "time creep." Richard already acknowledged that it was a simple bug and he supplied the fix. I applied it to my system, for what it's worth. I also messed up my clock in my clumsy effort to immediately force the correct ctime upon the time-stamp file, as you noticed.
Like I have said in the past If it ain't broke, don't fix it (break it)
More like "If you don't like it, lump it" or, perhaps, "My way or the highway."
I see no need for you to get offensive. I merely point out that something has worked well for many years, they change it and now people have problems. Perhaps better testing is in order then. And better documentation.
The point was not to give offense, but clearly the fixed-scheduling scheme _is_ broken and _does not_ work well for any installation that's not running on a continuous basis, and that's a lot of systems. Glib statements like yours don't rise to the level of engineering principles, they're just insults hurled by people who disagree with a decision that someone else made. And I believe in calling things as I see them.
-- Ken Schneider
Randall Schulz
On Saturday 07 May 2005 21:40, Randall R Schulz wrote:
The point was not to give offense, but clearly the fixed-scheduling scheme _is_ broken and _does not_ work well for any installation that's not running on a continuous basis, and that's a lot of systems.
But the system was never completely fixed time. It was always set up to run on the first opportunity after a reboot if the system wasn't up in the middle of the night. The present system is broken though, since if the scripts are run at noon they will continue to get run at noon. This is not a good idea.
On Sat, 2005-05-07 at 21:45 +0200, Anders Johansson wrote:
On Saturday 07 May 2005 21:40, Randall R Schulz wrote:
The point was not to give offense, but clearly the fixed-scheduling scheme _is_ broken and _does not_ work well for any installation that's not running on a continuous basis, and that's a lot of systems.
But the system was never completely fixed time. It was always set up to run on the first opportunity after a reboot if the system wasn't up in the middle of the night.
The present system is broken though, since if the scripts are run at noon they will continue to get run at noon. This is not a good idea.
Precisely my point, there has to be some sort of check against the system clock whether it is set correctly or not. If a job is meant to be run normally at 0000 and runs at 0800 when the system is booted it will always run at 0800, even on a system that crashed at 2340 and was booted at 0800 even though it normally runs 24/7. Not good for backups meant to run during the night. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Op zaterdag 7 mei 2005 21:53, schreef Ken Schneider:
Precisely my point, there has to be some sort of check against the system clock whether it is set correctly or not. If a job is meant to be run normally at 0000 and runs at 0800 when the system is booted it will always run at 0800, even on a system that crashed at 2340 and was booted at 0800 even though it normally runs 24/7. Not good for backups meant to run during the night.
cron.daily only takes care that jobs/scripts are run once every day. If you need more accurate timing, like e.g. your backup scripts you should use cron. -- Richard Bos Without a home the journey is endless
On Sunday 08 May 2005 00:16, Richard Bos wrote:
cron.daily only takes care that jobs/scripts are run once every day. If you need more accurate timing, like e.g. your backup scripts you should use cron.
As long as catman and updatedb are run by cron.daily, that's not good enough
Op zondag 8 mei 2005 00:18, schreef Anders Johansson:
cron.daily only takes care that jobs/scripts are run once every day. If you need more accurate timing, like e.g. your backup scripts you should use cron.
As long as catman and updatedb are run by cron.daily, that's not good enough
Sorry, I don't understand what you want to say. It is because they take to much time/processing power? -- Richard Bos Without a home the journey is endless
On Sunday 08 May 2005 00:21, Richard Bos wrote:
Op zondag 8 mei 2005 00:18, schreef Anders Johansson:
cron.daily only takes care that jobs/scripts are run once every day. If you need more accurate timing, like e.g. your backup scripts you should use cron.
As long as catman and updatedb are run by cron.daily, that's not good enough
Sorry, I don't understand what you want to say. It is because they take to much time/processing power?
Yes, they're the type of job you don't want to have running while you're working on other things. Especially on lower end hardware they will essentially guarantee that the computer can't do anything else until they're done. I know this isn't really the place to complain about these things, and perhaps I shouldn't be, but I thought I would mention it anyway since I'm afraid people will be seeing it happen when they install 9.3, and hopefully this post (or this entire thread) will go some way towards explaining why. The lines posted by Michael Nelson: 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 04 0 * * * root rm -f /var/spool/cron/lastrun/cron.daily 29 1 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 44 1 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly at the very least the three last ones, should be put back into crontab. Perhaps with a modification of the times. But it should be run when other things aren't being done.
Anders, On Saturday 07 May 2005 12:45, Anders Johansson wrote:
On Saturday 07 May 2005 21:40, Randall R Schulz wrote:
The point was not to give offense, but clearly the fixed-scheduling scheme _is_ broken and _does not_ work well for any installation that's not running on a continuous basis, and that's a lot of systems.
But the system was never completely fixed time. It was always set up to run on the first opportunity after a reboot if the system wasn't up in the middle of the night.
The present system is broken though, since if the scripts are run at noon they will continue to get run at noon. This is not a good idea.
I'll agree with that. I believe mine reset to around four PM at the time I first booted my new 9.3 install. Assuming I've sorted out the mess I made earlier, I'll be back on the 4:00 AM schedule starting tomorrow. Randall Schulz
On Saturday 07 May 2005 19:08, Randall R Schulz wrote:
Many users don't leave their systems running 24/7 and if the daily processing scheduling was done in the manner you suggest, it would simply be skipped if the system did not happen to be up at the selected time.
These two methods have existed in parallell for some time. run-crons runs all scripts for which there is no lock file, and checks the date on existing lock files. The only new thing is that they removed the manual deletion of lock files in crontab
On Sat, 2005-05-07 at 21:37 +0200, Anders Johansson wrote:
On Saturday 07 May 2005 19:08, Randall R Schulz wrote:
Many users don't leave their systems running 24/7 and if the daily processing scheduling was done in the manner you suggest, it would simply be skipped if the system did not happen to be up at the selected time.
These two methods have existed in parallell for some time. run-crons runs all scripts for which there is no lock file, and checks the date on existing lock files. The only new thing is that they removed the manual deletion of lock files in crontab
So the cronjobs run at their appointed time or when the system gets booted if it was shut down at the appointed run time. This makes it a little clearer. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Hello, On Saturday 07 May 2005 08:17, Richard Bos wrote:
Op zaterdag 7 mei 2005 17:12, schreef Scott Leighton:
test -e $SPOOL/$BASE && { case $BASE in cron.hourly) TIME="-cmin +60 -or -cmin 60" ;; cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;; cron.monthly) NOW=`date +%s` LASTMONTH=`date -d "last month" +%s` DIFF=`expr '(' $NOW - $LASTMONTH ')' / 86400` TIME="-ctime +$DIFF" ;; esac # remove all lock files for scripts that are due to run eval find $SPOOL/$BASE $TIME | \ xargs --no-run-if-empty rm }
I've stared and stared at it but can't see where it is bumping it by this weird 15 minute increase each day. Anyone have any clues?
It's already fixed for then next suse release ;)
Change:
cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;;
to
cron.daily) TIME="-cmin +1440 -or -cmin 1440" ;; cron.weekly) TIME="-cmin +10080 -or -cmin 10080" ;;
I'm imagine I'm the only one careless enough to make the mistake I did in applying the fix Richard posted here, but in case you're having problems getting the cron jobs to run after doing so, I should point out that not only did the numbers change, but the "-ctime" was changed to "-cmin". For those not cognizant of the myriad of options to the "find" command (a real trove of useful stuff, by the way), -ctime and friends (-atime and -mtime) measure "time" in days (i.e., the time range is their arguments times 24 hours). The -amin, -mmin and -cmin counterparts measure time in minutes. That's a factor of 1440 difference!
... -- Richard Bos
Randall Schulz
Richard, On Saturday 07 May 2005 08:17, Richard Bos wrote:
Op zaterdag 7 mei 2005 17:12, schreef Scott Leighton:
...
I've stared and stared at it but can't see where it is bumping it by this weird 15 minute increase each day. Anyone have any clues?
It's already fixed for then next suse release ;)
Change:
cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;;
to
cron.daily) TIME="-cmin +1440 -or -cmin 1440" ;; cron.weekly) TIME="-cmin +10080 -or -cmin 10080" ;;
Are you sure? My system still has the 15-minute-per-day creep after I applied this change. This is what my "/usr/lib/cron/run-crons" looks like now, with a bit more context: test -e $SPOOL/$BASE && { case $BASE in cron.hourly) TIME="-cmin +60 -or -cmin 60" ;; cron.daily) TIME="-cmin +1440 -or -ctime 1440" ;; cron.weekly) TIME="-cmin +10080 -or -ctime 10080" ;; cron.monthly) NOW=`date +%s` LASTMONTH=`date -d "last month" +%s` DIFF=`expr '(' $NOW - $LASTMONTH ')' / 86400` TIME="-ctime +$DIFF" ;; esac # remove all lock files for scripts that are due to run eval find $SPOOL/$BASE $TIME | \ xargs --no-run-if-empty rm }
...
Richard Bos
Randall Schulz
On Thu, May 19, 2005 at 06:36:24AM -0700, Randall R Schulz wrote:
Richard,
? ? ? ? ? cron.daily) ? TIME="-cmin ?+1440 -or -cmin ?1440" ?;; ? ? ? ? ? cron.weekly) ?TIME="-cmin ?+10080 -or -cmin ?10080" ?;;
Are you sure? My system still has the 15-minute-per-day creep after I applied this change.
Yes :))
This is what my "/usr/lib/cron/run-crons" looks like now, with a bit more context:
test -e $SPOOL/$BASE && { case $BASE in cron.hourly) TIME="-cmin +60 -or -cmin 60" ;; cron.daily) TIME="-cmin +1440 -or -ctime 1440" ;; cron.weekly) TIME="-cmin +10080 -or -ctime 10080" ;;
The both ctimes should be cmin as well, (see above). -- Richard
Richard, On Thursday 19 May 2005 06:43, radoeka wrote:
On Thu, May 19, 2005 at 06:36:24AM -0700, Randall R Schulz wrote:
Richard,
? ? ? ? ? cron.daily) ? TIME="-cmin ?+1440 -or -cmin ?1440" ?;; ? ? ? ? ? cron.weekly) ?TIME="-cmin ?+10080 -or -cmin ?10080" ?;;
Are you sure? My system still has the 15-minute-per-day creep after I applied this change.
Yes :))
This is what my "/usr/lib/cron/run-crons" looks like now, with a bit
more context:
test -e $SPOOL/$BASE && { case $BASE in cron.hourly) TIME="-cmin +60 -or -cmin 60" ;; cron.daily) TIME="-cmin +1440 -or -ctime 1440" ;; cron.weekly) TIME="-cmin +10080 -or -ctime 10080" ;;
The both ctimes should be cmin as well, (see above).
D'Oh! D'Oh! D'Oh!
-- Richard
Thanks. Randall "Homer" Schulz
participants (7)
-
Anders Johansson -
Ken Schneider -
Michael Nelson -
radoeka -
Randall R Schulz -
Richard Bos
-
Scott Leighton