what the heck keeps running at 1am?
Most, but not all, nights several things run in the background. This includes the following that I have seen active (via "top") during this time period each time: find, sort, rpm, grep, and cleanup. It is not (or at least should not) be my cron jobs as my cron is set up to run at 6am (I attached /etc/crontab at end of email, in case I unwittingly messed it up). What else runs around 1am that may include some/all of the above mentioned programs? Only my cron.daily and cron.d directories have anything in them. I only know of "at" and "cron" that run on time delays, and "at" is empty, while crontab times are listed below. Any ideas? Thanks -jeric /etc/crontab: -*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 14 6 * * * root rm -f /var/spool/cron/lastrun/cron.daily 29 6 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 44 6 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly -- JericAtSbcglobalDotNetwork 1:05am up 1 day, 1:52, 6 users, load average: 1.74, 1.37, 0.85
On Sunday 29 December 2002 11:15 pm, Jeric wrote:
Most, but not all, nights several things run in the background. This includes the following that I have seen active (via "top") during this time period each time: find, sort, rpm, grep, and cleanup.
It is not (or at least should not) be my cron jobs as my cron is set up to run at 6am (I attached /etc/crontab at end of email, in case I unwittingly messed it up). [...] -*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 14 6 * * * root rm -f /var/spool/cron/lastrun/cron.daily 29 6 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 44 6 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly
It took me a moment, but I think I found your "goof" -- the change you made [changing the first "0" to a "6" in the last three lines] changed the time that the LOGGED OUTPUT GETS DELETED from "midnite-ish" to "six-a.m.-ish" -- take a careful look at the line(s): the "command" being executed is rm -f /var/spool/cron/lastrun/cron.<interval> "rm" is, of course, the delete command. The basic idea here [I gather] is to delete the "last run" information "just prior to" actually running the command(s) for the next hour/day/week/month. The first line shows what really happens: every 15 minutes, the command test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 gets executed -- the command "test" tests for the existance of the file /usr/lib/cron/run-crons, and if it exists, it executes it [the "test first/run later" bit is done to avoid generating errors every 15 minutes "because the file doesn't exist..." In any case, the file "run-crons" gets executed, and from what I can tell, it is basically a shell script that duplicates the functionality of cron itself (insert sound of head smacking into brick wall here...) In particular, the segment that begins: #set verbose ## stage 1, search directories/scripts to run executes the following test: 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) TIME="-ctime +`date -u +%d`" ;; esac [executed against each of the files/directorys cron.hourly/daily etc.] In other words, it tests the time as being "the top of the hour" for cron.hourly; "1am" for cron.daily; etc. -- not a whole lot different than the fact that cron itself "tests for the time" and sees what it has to run...
On Mon, 2002-12-30 at 02:15, Tom Emerson wrote:
insert sound of head smacking into brick wall here... *smack* ... done ;^)
Thanks for help and pointing that file entry out. So, if I have read everything better this time, then by altering the -ctimes in the /usr/lib/cron/run-crons script, then that should alter the time of the actually running of the cron jobs... so, "-ctime +6 -or -ctime 6" should start it at 6am? I have now altered the /etc/crontab, /usr/lib/cron/run-crons, /etc/cron.d/envlogmgr.cron, and /etc/cron.d/seccheck activation times to run +6 hours for each entry. Provided that I keep their intervals in the same order, do I still run the risk of hosing my computer by doing all this? Thanks again, -Jeric -- JericAtSbcglobalDotNetwork 2:50am up 1 day, 3:36, 6 users, load average: 0.11, 0.08, 0.10
On Monday 30 December 2002 1:07 am, Jeric wrote:
On Mon, 2002-12-30 at 02:15, Tom Emerson wrote:
insert sound of head smacking into brick wall here... *smack* ... done ;^)
[heh heh heh -- that "insert sound" wasn't for you doing something boneheaded, it was for me in regards to the various developers that came up with this "scheme" -- like I said, run-crons duplicates what cron does in the first place, with a LOT more "confusion" than need be -- however, I suspect by the time you're done with this, your head will hurt worse than mine :) ]
Thanks for help and pointing that file entry out.
So, if I have read everything better this time, then by altering the -ctimes in the /usr/lib/cron/run-crons script, then that should alter the time of the actually running of the cron jobs... so, "-ctime +6 -or -ctime 6" should start it at 6am?
no, it is much more complex than that... The next step performs this: eval find $SPOOL/$BASE $TIME | \ xargs --no-run-if-empty rm which has at it's core a "find" command that expands like this: find /var/spool/cron/lastrun/cron.daily -ctime 1 -or -ctime +1 which translates into "programmer-ese" as if last_state_change(/var/spool/cron/lastrun/cron.daily) >= 1_day then [execute the eval command] at least, that's what I think it means (getting too late in the day to really be writing this, and besides, I just took some cold medicine to keep my sinuses clear as I sleep...)
I have now altered the /etc/crontab, /usr/lib/cron/run-crons, /etc/cron.d/envlogmgr.cron, and /etc/cron.d/seccheck activation times to run +6 hours for each entry. Provided that I keep their intervals in the same order, do I still run the risk of hosing my computer by doing all this?
should be low risk -- as I recall, about the only thing that actually DOES anything is cron.daily [unless you've added something of your own, but if you were sane you'd have added it as a real cron entry in the first place...] From the command "l /etc/cron*" I get the following for the cron.daily directory: cron.daily: total 49 -rwx------ 924 Sep 10 17:53 clean_catman* -rwx------ 1740 Sep 10 13:20 clean_core* -rwx------ 1169 Sep 10 17:53 do_mandb* -rwxr-xr-x 51 Sep 9 12:58 logrotate* -rwxr-xr-x 1864 Jul 29 08:26 suse.de-backup-rc.config* -rwxr-xr-x 1974 May 21 2002 suse.de-backup-rpmdb* -rwxr-xr-x 573 Feb 7 2002 suse.de-check-battery* -rwxr-xr-x 1138 May 21 2002 suse.de-clean-tmp* -rwxr-xr-x 461 Feb 7 2002 suse.de-clean-vi* -rwxr-xr-x 360 May 21 2002 suse.de-cron-local* -rwx------ 1515 Sep 10 13:20 updatedb* which is all "housekeeping" stuff -- cleaning up temp directories, running "updatedb" [for the "locate" command to work], rotating log files [which never seems to work "out of the box" anyway -- my "/var/log/messages" file dates back to early october, but should be rotated a bit more frequently... gotta remember to check on that...] So, "if it doesn't happen" [because of a munged run-crons script] nothing bad will happen (he said ever so confidently...)
The 02.12.30 at 01:50, Tom Emerson wrote:
[heh heh heh -- that "insert sound" wasn't for you doing something boneheaded, it was for me in regards to the various developers that came up with this "scheme" -- like I said, run-crons duplicates what cron does in the first place, with a LOT more "confusion" than need be --
Not exactly. The idea of run-crun is to make sure that certain things run at least once a day, or a week, or whatever interval, regardless of the hours the machine is actually on. I mean, if you switch the computer off at 18:00 hours, and power it on two days later at, say, 10:00, the daily scripts will then run at 10:15. There is another cron daemon designed for that, I think it is called anacron, or something like that. -- Cheers, Carlos Robinson
participants (3)
-
Carlos E. R. -
Jeric -
Tom Emerson