Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
RE: [SLE] cron not recognizing changes to /etc/cron.d files [SOLVED]
  • From: "Greg Wallace" <gregwallace@xxxxxxxxxxx>
  • Date: Fri, 7 Apr 2006 23:23:01 -0500
  • Message-id: <!&!AAAAAAAAAAAYAAAAAAAAABYv/fsiAbFHuuseWu7lbHnCgAAAEAAAAKBg7pbp9xtJqGDxjxFtVWQBAAAAAA==@xxxxxxxxxxx>
On Friday, April 07, 2006 @ 10:52 PM, Scott Leighton wrote:

>On Friday 07 April 2006 3:29 am, Joachim Schrod wrote:
>> Scott Leighton wrote:
>> > cron uses the directory timestamps to decide whether or not
>> > to reload crontabs. The various important directories that it monitors
>> > include /etc/cron.d, /etc/cron.daily, /etc/cron.hourly,
>> > /etc/cron.monthly and the user crontabs at /var/spool/cron/tabs
>>
>> Almost. :-)
>>
>> cron monitors directory timestamp of /etc/cron.d and /var/spool/cron/tabs
>> and the file timestamp of /etc/crontab. This is explained in the man page
>> of cron, in the 3rd paragraph.

> Empirical evidence says the man page is incomplete. The timestamps
>of the /etc/cron.{d,daily,hourly,monthly} directories are most certainly
>monitored on the systems I have here. If the directory timestamp is
>updated, the the files in the directory are examined and any changed
>ones are reloaded by the cron daemon. Test it yourself, you'll see
>RELOAD messages in your log from the daemon.

>>
>> cron does not monitor /etc/cron.{daily,hourly,monthly}. These scripts are
>> executed by /usr/lib/cron/run-crons which is called in /etc/crontab every
>> 15 minutes.

> Almost. ;-)
>
> run-crons tests for the presence of lockfiles, it has nothing to do with
>the cached scripts that crond is dealing with. run-crons will trigger the
>deletion of the lockfiles, that in turn causes crond to execute the cached
>files. All of which has absolutely nothing to do with my problem.


>> While I'm at it: The actual time when daily jobs are executed is
determined
>> by the creation time stamp of /var/spool/cron/lastrun/cron.daily. Since
>> this is the creation time stamp, one cannot change the time by touching
the
>> file. Instead, one must remove it with an at job. (Which is a brain-dead
>> design decision, IMHO.)

> Yes, that one bit me in the butt months and months ago... there's a few
>threads in the archive on that subject. I agree, the design is poor, but I
>kinda understand why they made the decision since a lot of systems (laptops
>in particular) aren't running 24/7.


> Scott

Pardon the interruption, but I had been led to believe that a creation date
was not maintained in Linux file systems - only last access and last
modified. What command can you use to access the creation time stamp?
Again, pardon the interruption, but I'd really like to know how to access
this information.

Greg Wallace



< Previous Next >
References