cron not recognizing changes to /etc/cron.d files
I'm running SUSE 9.3 on two machines, a 64 bit installation at home and a 32 bit installation at work. Both machines are up to date with all YOU updates and are configured similarly. The work machine doesn't seem to be recognizing changes made to cron files in /etc/cron.d, that is, a RELOAD of the changed file never happens and doesn't show in the log. I basically have to rccron restart to get the cron daemon to use the new file. The home machine does recognize changes, a RELOAD will take place within a minute or so after saving the changed file back to /etc/cron.d I've checked ownership (root) and permissions (600) on both boxes, they are the same, so I'm looking for ideas on where to look next to figure out what is causing the work machine to not see the changes made to /etc/cron.d files. Any ideas will be appreciated, I'm pretty much stumped right now. Scott -- Difficile est saturam non scribere POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
* Scott Leighton <helphand@pacbell.net> [04-06-06 22:29]:
The work machine doesn't seem to be recognizing changes made to cron files in /etc/cron.d, that is, a RELOAD of the changed file never happens and doesn't show in the log. I basically have to rccron restart to get the cron daemon to use the new file.
What command are you issueing to edit cron? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Thursday 06 April 2006 7:37 pm, Patrick Shanahan wrote:
* Scott Leighton <helphand@pacbell.net> [04-06-06 22:29]:
The work machine doesn't seem to be recognizing changes made to cron files in /etc/cron.d, that is, a RELOAD of the changed file never happens and doesn't show in the log. I basically have to rccron restart to get the cron daemon to use the new file.
What command are you issueing to edit cron?
On both boxes, I tend to use either kate or mcedit to edit these files. I just edited one on my home box (the one that works) using mcedit, cron detected the change and did a RELOAD of the changed file within a minute, here's the log entry Apr 6 19:45:01 helphand /usr/sbin/cron[7027]: (*system*) RELOAD (/etc/cron.d/seccheck) Scott -- Ab urbe condita POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
On Thursday 06 April 2006 7:37 pm, Patrick Shanahan wrote:
* Scott Leighton <helphand@pacbell.net> [04-06-06 22:29]:
The work machine doesn't seem to be recognizing changes made to cron files in /etc/cron.d, that is, a RELOAD of the changed file never happens and doesn't show in the log. I basically have to rccron restart to get the cron daemon to use the new file.
What command are you issueing to edit cron?
Not sure if this is relevant or not, but I just noticed that the directory timestamp changed on the box that works, but doesn't seem to change on the box that doesn't work. Box that works - note seccheck timestamp and directory timestamp match drwxr-xr-x 2 root root 184 2006-04-06 19:44 ./ drwxr-xr-x 100 root root 9208 2006-04-02 09:05 ../ -rw------- 1 root root 89 2004-05-30 22:17 amavis_clean -rw------- 1 root root 150 2005-12-18 20:25 amavis-stats -rw------- 1 root root 133 2006-04-06 19:18 leafnode -rw------- 1 root root 124 2005-07-08 22:24 parselog -rw------- 1 root root 369 2006-04-06 19:44 seccheck Box that doesn't work - note that last file changed, hss, timestamp and directory timestamp do not match drwxr-xr-x 2 root root 120 2006-04-05 17:08 ./ drwxr-xr-x 79 root root 7016 2006-04-04 06:54 ../ -rw------- 1 root root 79 2005-03-19 11:27 awstats -rw------- 1 root root 1354 2006-04-06 10:10 hss -rw------- 1 root root 369 2005-03-19 12:08 seccheck Scott -- Deus et natua non faciunt frusta POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
* Scott Leighton <helphand@pacbell.net> [04-06-06 22:46]:
On both boxes, I tend to use either kate or mcedit to edit these files. I just edited one on my home box (the one that works) using mcedit, cron detected the change and did a RELOAD of the changed file within a minute, here's the log entry
Apr 6 19:45:01 helphand /usr/sbin/cron[7027]: (*system*) RELOAD (/etc/cron.d/seccheck)
try using: crontab -e -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Thursday 06 April 2006 8:19 pm, Patrick Shanahan wrote:
* Scott Leighton <helphand@pacbell.net> [04-06-06 22:46]:
On both boxes, I tend to use either kate or mcedit to edit these files. I just edited one on my home box (the one that works) using mcedit, cron detected the change and did a RELOAD of the changed file within a minute, here's the log entry
Apr 6 19:45:01 helphand /usr/sbin/cron[7027]: (*system*) RELOAD (/etc/cron.d/seccheck)
try using: crontab -e
Humm, don't think so. crontab -e is for editing user crontabs, the files in /etc/cron.d are not user crontabs. In fact, if I login root and issue crontab -e, what I see is root's crontab from /var/spool/cron/tabs/ The cron files in /etc/cron.d, /etc/cron.daily, /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly are not meant to be edited with crontab -e as I understand it. Scott -- Si vis amari, ama POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
* Scott Leighton <helphand@pacbell.net> [04-06-06 23:30]:
The cron files in /etc/cron.d, /etc/cron.daily, /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly are not meant to be edited with crontab -e as I understand it.
no, they are not. But I believe that you need to do 'rccron restart' after editing the system crontabs. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Thursday 06 April 2006 8:35 pm, Patrick Shanahan wrote:
* Scott Leighton <helphand@pacbell.net> [04-06-06 23:30]:
The cron files in /etc/cron.d, /etc/cron.daily, /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly are not meant to be edited with crontab -e as I understand it.
no, they are not. But I believe that you need to do 'rccron restart' after editing the system crontabs.
OK, here's what I've found out. 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 The crontab program automatically takes care of updating the directory timestamp for /var/spool/cron/tabs if a user changes their tab with crontab -e. Some editors, like vim, also change directory timestamps when you edit a file, so they have the effect of essentially acting like crontab -e would when used on a system cron file saved at /etc/cron* My particular issue is that I've come to expect that the editor I am primarily using, mcedit, acts right and changes the directory timestamp. Unfortunately, it apparently doesn't always do so (which is a whole new issue) since it acts one way on my home system and a completely different way on my work system (I've compared the ~/.mc/ini files on both systems, they are identical, so I don't think it is a config issue, but I'm still looking). Anyways, bottom line, the issue really isn't a cron issue since the behavior is really caused by the editor used, not cron itself. Scott -- Paucis verbis, quid est deconstructionismus? POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
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. 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. 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.) HTH, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
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 -- Vesanum poetam qui sapiunt fugiunt POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
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
On Friday 07 April 2006 9:23 pm, Greg Wallace wrote:
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.
You can't, only last access and last modified can be accessed. The paragraph you responded to specifically stated the same, so I'm guessing you may be thinking that earlier references in the post were talking about creation timestamps, but they weren't. The post kinda changed subject at the end. Scott -- De duobus malis, minus est semper eligendum POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
Greg Wallace wrote:
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.
Sorry, this was jargon. What actually is tested is the so-called "ctime", the time of last modification of file status information. It can be shown by the -lc options of ls. If the file has not been renamed and not edited, as it is the case for this timestamp flag file, it is the time of creation. With touch one can change the last modification date, but not the file status change date. In fact, I never understood why run-crons uses the find options -ctime and -cmin, and not -mtime and -mmin. That would allow us users to change the execution time of daily scripts with a single touch command, which would be *much* better than the current solution to delete the timestamp file with in an at job. While this is not a bug, it is still a nuisance. OTOH, my experience with SUSE's ticket system is not such that the effort to open a ticket there would be time well spent. By the way, the full formal definition of ctime is buried in the pit of the Single Unix Specification; where every function that changes the ctime value says so explicitly in its description. See http://www.opengroup.org/onlinepubs/009695399/toc.htm Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
On Sunday, April 09, 2006 @ 2:50 PM, Joachim Schrod wrote:
Greg Wallace wrote:
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.
Sorry, this was jargon.
What actually is tested is the so-called "ctime", the time of last modification of file status information. It can be shown by the -lc options of ls.
If the file has not been renamed and not edited, as it is the case for this
timestamp flag file, it is the time of creation. With touch one can change the last modification date, but not the file status change date.
In fact, I never understood why run-crons uses the find options -ctime and -cmin, and not -mtime and -mmin. That would allow us users to change the execution time of daily scripts with a single touch command, which would be
*much* better than the current solution to delete the timestamp file with in an at job. While this is not a bug, it is still a nuisance. OTOH, my experience with SUSE's ticket system is not such that the effort to open a ticket there would be time well spent.
By the way, the full formal definition of ctime is buried in the pit of the
Single Unix Specification; where every function that changes the ctime value says so explicitly in its description. See http://www.opengroup.org/onlinepubs/009695399/toc.htm
Joachim
Joachim: I promise I'm not trying to steal this thread, but I'm going to push my luck and ask a question. What type of action changes the file's status change date (and would that also necessarily change the file's creation/modification date?)? Thanks, Greg Wallace
On Monday 10 April 2006 06:49, Greg Wallace wrote:
On Sunday, April 09, 2006 @ 2:50 PM, Joachim Schrod wrote:
Greg Wallace wrote: Joachim:
I promise I'm not trying to steal this thread, but I'm going to push my luck and ask a question. What type of action changes the file's status change date (and would that also necessarily change the file's creation/modification date?)?
Do you mean 'touch'? Try 'man touch' and see if that meets your description. Cheers, Leen
Leendert Meyer wrote:
On Monday 10 April 2006 06:49, Greg Wallace wrote:
I promise I'm not trying to steal this thread, but I'm going to push my luck and ask a question. What type of action changes the file's status change date (and would that also necessarily change the file's creation/modification date?)?
Do you mean 'touch'? Try 'man touch' and see if that meets your description.
As posted already several times in this thread, touch is not able to set the file status change date, aka st_ctime in <sys/stat.h>. In fact, I don't know of any C function that could set it. If you know one, speak up and tell us. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
On Monday 10 April 2006 12:33, Joachim Schrod wrote:
Leendert Meyer wrote:
On Monday 10 April 2006 06:49, Greg Wallace wrote:
I promise I'm not trying to steal this thread, but I'm going to push my luck and ask a question. What type of action changes the file's status change date (and would that also necessarily change the file's creation/modification date?)?
Do you mean 'touch'? Try 'man touch' and see if that meets your description.
As posted already several times in this thread, touch is not able to set
Sorry, I did not follow the thread from its beginnings. Gregs way of phrasing tricked me into answering mode (my choice and my bad). ;)
the file status change date, aka st_ctime in <sys/stat.h>. In fact, I don't
I do not have a <sys/stat.h> in /usr/include/, but a <bits/stat.h>, but st_ctime is mentioned there too. From that I conclude that st_ctime is also named the "file's creation time". Correct?
know of any C function that could set it. If you know one, speak up and tell us.
No. But in a shell one posibility could be 'cat f.txt > tmp.txt; cat tmp.txt > f.txt; rm tmp.txt'. But a shell is not C. This is a bit out of my league, so I'll step back. ;) Cheers, Leen
Leendert Meyer wrote:
the file status change date, aka st_ctime in <sys/stat.h>. In fact, I don't
I do not have a <sys/stat.h> in /usr/include/, but a <bits/stat.h>, but st_ctime is mentioned there too.
You're right that the actual definition of st_ctime is in bits/stat.h. But sys/stat.h is the canonical include file that is used to get at that definition, as per the POSIX standard. And I'm quite sure that if you have a bits/stat.h, you have a sys/stat.h as well, as both are in the same rpm package, namely glibc-devel.
From that I conclude that st_ctime is also named the "file's creation time". Correct?
No. st_ctime is the file status change timestamp. It is updated on any change to the file or the file's name or other timestamps. In the original context of this thread, where it was mentioned for the timestamp flag file /var/spool/cron/lastrun/cron.daily, st_ctime is the creation time, but this is not the general semantics.
know of any C function that could set it. If you know one, speak up and tell us.
No. But in a shell one posibility could be 'cat f.txt > tmp.txt; cat tmp.txt > f.txt; rm tmp.txt'. But a shell is not C.
Updating it to the current time can be done with touch. What we are looking for is an easy method to set it to some arbitrary timestamp, in the past or in the future. The ctime of the file cited above is the time when the jobs in /etc/cron.daily are run. Some people, who don't turn their systems off, want these jobs to be run in the night. For that, they need to change the ctime of that file, let's say to 04:45 or something like that. touch won't work here. The only known way to do that is by typing: $ at 04:43 > rm /var/spool/cron/lastrun/cron.daily > <EOF> (where <EOF> is typically Ctrl-D). Then that file will be (re-)created by the cron job that starts at 04:45. We are looking for a method that does the above more easily and can be explained more easily to newbies. Best, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
Op maandag 10 april 2006 17:01, schreef Joachim Schrod:
Updating it to the current time can be done with touch. What we are looking for is an easy method to set it to some arbitrary timestamp, in the past or in the future. The ctime of the file cited above is the time when the jobs in /etc/cron.daily are run. Some people, who don't turn their systems off, want these jobs to be run in the night. For that, they need to change the ctime of that file, let's say to 04:45 or something like that. touch won't work here. The only known way to do that is by typing:
$ at 04:43
> rm /var/spool/cron/lastrun/cron.daily > <EOF>
(where <EOF> is typically Ctrl-D). Then that file will be (re-)created by the cron job that starts at 04:45. We are looking for a method that does the above more easily and can be explained more easily to newbies.
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily -- Richard Bos Without a home the journey is endless
On Monday 10 April 2006 20:39, Richard Bos wrote:
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily
From that file:
In SuSe 9.3 touch modifies all 3 access times to the touch time if used without the -t flag!!
The same for SUSE 10.0 - I just checked. :) Cheers, Leen
On Monday, April 10, 2006 @ 1:47 PM, Leendert Meyer wrote:
On Monday 10 April 2006 20:39, Richard Bos wrote:
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily
From that file:
In SuSe 9.3 touch modifies all 3 access times to the touch time if used without the -t flag!!
The same for SUSE 10.0 - I just checked. :)
Cheers,
Leen
If you wouldn't mind, just to satisfy my own curiosity, what are the 3 timestamps that are being touched? In various other threads on this list, I came away with the impression that there were only two timestamps being maintained by any of the underlying file systems (Reiser, EXT2, EXT3, etc.). Is this not true? Are there actually 3 timestamps being maintained for a single file/directory at file system level, or, in this case, is it done via some software implemented mechanism? Thanks, Greg Wallace Greg Wallace
On Monday 10 April 2006 21:25, Greg Wallace wrote:
On Monday, April 10, 2006 @ 1:47 PM, Leendert Meyer wrote:
On Monday 10 April 2006 20:39, Richard Bos wrote:
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily
From that file:
In SuSe 9.3 touch modifies all 3 access times to the touch time if used without the -t flag!!
The same for SUSE 10.0 - I just checked. :)
Cheers,
Leen
If you wouldn't mind, just to satisfy my own curiosity, what are the 3 timestamps that are being touched? In various other threads on this list, I came away with the impression that there were only two timestamps being maintained by any of the underlying file systems (Reiser, EXT2, EXT3, etc.). Is this not true? Are there actually 3 timestamps being maintained for a single file/directory at file system level, or, in this case, is it done via some software implemented mechanism?
Here's the output from test I did: ---<cut>--- leen@ws-03:~> f="test.txt"; rm -f $f; echo "a" > $f; stat $f; sleep 10; touch $f; stat $f File: `test.txt' Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:33.000000000 +0200 Modify: 2006-04-10 21:33:33.000000000 +0200 Change: 2006-04-10 21:33:33.000000000 +0200 File: `test.txt' Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:44.000000000 +0200 Modify: 2006-04-10 21:33:44.000000000 +0200 Change: 2006-04-10 21:33:44.000000000 +0200 leen@ws-03:~> ---<cut>--- Cheers, Leen
On Monday 10 April 2006 21:36, Leendert Meyer wrote:
On Monday 10 April 2006 21:25, Greg Wallace wrote:
On Monday, April 10, 2006 @ 1:47 PM, Leendert Meyer wrote:
On Monday 10 April 2006 20:39, Richard Bos wrote:
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily
From that file:
In SuSe 9.3 touch modifies all 3 access times to the touch time if used without the -t flag!!
The same for SUSE 10.0 - I just checked. :)
Cheers,
Leen
If you wouldn't mind, just to satisfy my own curiosity, what are the 3 timestamps that are being touched? In various other threads on this list, I came away with the impression that there were only two timestamps being maintained by any of the underlying file systems (Reiser, EXT2, EXT3, etc.). Is this not true? Are there actually 3 timestamps being maintained for a single file/directory at file system level, or, in this case, is it done via some software implemented mechanism?
I forgot to answer your other question: I always understood that there are 3 timestamps maintained in the filesystem: creation, access and modification. As I learned today, the creation time is actually the time of the last state change. And it must be part of the filesystem (on disk), how would it else work across e.g. reboots?
Here's the output from test I did: ---<cut>--- leen@ws-03:~> f="test.txt"; rm -f $f; echo "a" > $f; stat $f; sleep 10; touch $f; stat $f File: `test.txt' Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:33.000000000 +0200 Modify: 2006-04-10 21:33:33.000000000 +0200 Change: 2006-04-10 21:33:33.000000000 +0200 File: `test.txt' Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:44.000000000 +0200 Modify: 2006-04-10 21:33:44.000000000 +0200 Change: 2006-04-10 21:33:44.000000000 +0200 leen@ws-03:~> ---<cut>---
Cheers, Leen
On Monday 10 April 2006 21:36, Leendert Meyer wrote:
On Monday 10 April 2006 21:25, Greg Wallace wrote:
On Monday, April 10, 2006 @ 1:47 PM, Leendert Meyer wrote:
On Monday 10 April 2006 20:39, Richard Bos wrote:
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily
From that file:
In SuSe 9.3 touch modifies all 3 access times to the touch time if used without the -t flag!!
The same for SUSE 10.0 - I just checked. :)
Cheers,
Leen
If you wouldn't mind, just to satisfy my own curiosity, what are the 3 timestamps that are being touched? In various other threads on this list, I came away with the impression that there were only two timestamps being maintained by any of the underlying file systems (Reiser, EXT2, EXT3, etc.). Is this not true? Are there actually 3 timestamps being maintained for a single file/directory at file system level, or, in
On Monday, April 10, 2006 @ 2:41 PM, Leendert Meyer wrote: this
case, is it done via some software implemented mechanism?
I forgot to answer your other question:
I always understood that there are 3 timestamps maintained in the filesystem: creation, access and modification. As I learned today, the creation time is
actually the time of the last state change. And it must be part of the filesystem (on disk), how would it else work across e.g. reboots?
I see. I remember for sure that it was stated in earlier threads that there was no creation time maintained, but I also thought it was stated that there were only 2 dates stored at file system level. As you say, though, it would seem that there must be 3 dates at file system level, which are (hope I have this right) 1) state change, 2) access, and 3) modification. I know that with the ls command you say -c to get the status (I guess the same as state) modification time and without the -c you get (I think) modification time. It would be nice if there was a simple command that would show you all 3 dates for a particular file/directory.
Here's the output from test I did: ---<cut>--- leen@ws-03:~> f="test.txt"; rm -f $f; echo "a" > $f; stat $f; sleep 10; touch $f; stat $f File: `test.txt' Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:33.000000000 +0200 Modify: 2006-04-10 21:33:33.000000000 +0200 Change: 2006-04-10 21:33:33.000000000 +0200 File: `test.txt' Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:44.000000000 +0200 Modify: 2006-04-10 21:33:44.000000000 +0200 Change: 2006-04-10 21:33:44.000000000 +0200 leen@ws-03:~> ---<cut>---
Cheers,
Leen
On Monday 10 April 2006 22:06, Greg Wallace wrote:
On Monday, April 10, 2006 @ 2:41 PM, Leendert Meyer wrote:
On Monday 10 April 2006 21:36, Leendert Meyer wrote:
On Monday 10 April 2006 21:25, Greg Wallace wrote:
On Monday, April 10, 2006 @ 1:47 PM, Leendert Meyer wrote:
On Monday 10 April 2006 20:39, Richard Bos wrote:
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily
From that file:
In SuSe 9.3 touch modifies all 3 access times to the touch time if used without the -t flag!!
The same for SUSE 10.0 - I just checked. :)
Cheers,
Leen
If you wouldn't mind, just to satisfy my own curiosity, what are the 3 timestamps that are being touched? In various other threads on this list, I came away with the impression that there were only two
timestamps
being maintained by any of the underlying file systems (Reiser, EXT2, EXT3, etc.). Is this not true? Are there actually 3 timestamps being maintained for a single file/directory at file system level, or, in
this
case, is it done via some software implemented mechanism?
I forgot to answer your other question:
I always understood that there are 3 timestamps maintained in the filesystem: creation, access and modification. As I learned today, the creation time is
actually the time of the last state change. And it must be part of the filesystem (on disk), how would it else work across e.g. reboots?
I see. I remember for sure that it was stated in earlier threads that there was no creation time maintained, but I also thought it was stated that there were only 2 dates stored at file system level. As you say, though, it would seem that there must be 3 dates at file system level, which are (hope I have this right) 1) state change, 2) access, and 3) modification.
Yes.
I know that with the ls command you say -c to get the status (I guess the same as state) modification time and without the -c you get (I think) modification time. It would be nice if there was a simple command that would show you all 3 dates for a particular file/directory.
There is: stat. Look at my output below:
Here's the output from test I did: ---<cut>--- leen@ws-03:~> f="test.txt"; rm -f $f; echo "a" > $f; stat $f; sleep 10; touch $f; stat $f File: `test.txt'
output from 1st stat cmd:
Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:33.000000000 +0200 Modify: 2006-04-10 21:33:33.000000000 +0200 Change: 2006-04-10 21:33:33.000000000 +0200 File: `test.txt' Size: 2 Blocks: 8 IO Block: 4096 regular file
output from 2nd stat cmd:
Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:44.000000000 +0200 Modify: 2006-04-10 21:33:44.000000000 +0200 Change: 2006-04-10 21:33:44.000000000 +0200 leen@ws-03:~> ---<cut>---
Have a look at 'man stat' too, it shows all kinds of nice formatting options. ;) Cheers, Leen
On Monday, April 10, 2006 @ 3:17 PM, Leendert Meyer wrote: <snip>
I know that with the ls command you say -c to get the status (I guess the same as state) modification time and without the -c you get (I think) modification time. It would be nice if there was a simple command that would show you all 3 dates for a particular file/directory.
There is: stat. Look at my output below:
Here's the output from test I did: ---<cut>--- leen@ws-03:~> f="test.txt"; rm -f $f; echo "a" > $f; stat $f; sleep 10; touch $f; stat $f File: `test.txt'
output from 1st stat cmd:
Size: 2 Blocks: 8 IO Block: 4096 regular file Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:33.000000000 +0200 Modify: 2006-04-10 21:33:33.000000000 +0200 Change: 2006-04-10 21:33:33.000000000 +0200 File: `test.txt' Size: 2 Blocks: 8 IO Block: 4096 regular file
output from 2nd stat cmd:
Device: 308h/776d Inode: 326689 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ leen) Gid: ( 100/ users) Access: 2006-04-10 21:33:44.000000000 +0200 Modify: 2006-04-10 21:33:44.000000000 +0200 Change: 2006-04-10 21:33:44.000000000 +0200 leen@ws-03:~> ---<cut>---
Have a look at 'man stat' too, it shows all kinds of nice formatting options. ;)
Cheers,
Leen
Nice! I didn't realize it was that easy. I'll have to look at some files on my system using this. Have you seen any files with all 3 dates being different? Greg Wallace
On Tuesday 11 April 2006 01:11, Greg Wallace wrote:
On Monday, April 10, 2006 @ 3:17 PM, Leendert Meyer wrote:
Have a look at 'man stat' too, it shows all kinds of nice formatting options. ;)
Nice! I didn't realize it was that easy. I'll have to look at some files on my system using this. Have you seen any files with all 3 dates being different?
No, but I didn't look for them very hard. ;P It wouldn't be too difficult to write a little script that checks every file on your system and reports the file(s) that have all 3 times different. Cheers, Leen
On Tuedsay, April 11, 2006 @ 2:56 Am, Leendert Meyer wrote:
On Tuesday 11 April 2006 01:11, Greg Wallace wrote:
On Monday, April 10, 2006 @ 3:17 PM, Leendert Meyer wrote:
Have a look at 'man stat' too, it shows all kinds of nice formatting options. ;)
Nice! I didn't realize it was that easy. I'll have to look at some files on my system using this. Have you seen any files with all 3 dates being different?
No, but I didn't look for them very hard. ;P It wouldn't be too difficult to write a little script that checks every file on your system and reports the
file(s) that have all 3 times different.
Cheers,
Leen
I found some almost right away. I still don't really understand when each date is changed. I would like to try to create a new file and get all 3 dates set to different values. That would give me more insight into how this works. Something to tinker with somewhere along the line. Greg Wallace
Greg Wallace wrote:
I found some almost right away. I still don't really understand when each date is changed.
Basically: atime, the "access time": whenever a file is opened for reading and closed afterwards. mtime, the "modified time": whenever a file is written to. ctime, the "status change time": whenever a file is written to, its name, or other meta information is changed. Now the exception for atime: File systems can be mounted with a flag that causes the atime not to be updated on read access (option noatime). The NFS server also doesn't update atime on reading (well, sometimes); thus this information on NFS-mounted file systems is not always true.
I would like to try to create a new file and get all 3 dates set to different values.
I don't know of any way to do that. You can change the atime and the mtime with touch later, after creation. Each touch will update ctime, since you update meta information about the file (see above). HTH, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
On Wednesday, April 12, 2006 @ 8:00 AM, Joachim Schrod wrote:
Greg Wallace wrote:
I found some almost right away. I still don't really understand when
each
date is changed.
Basically:
atime, the "access time": whenever a file is opened for reading and closed afterwards.
mtime, the "modified time": whenever a file is written to.
ctime, the "status change time": whenever a file is written to, its name, or other meta information is changed.
Now the exception for atime: File systems can be mounted with a flag that causes the atime not to be updated on read access (option noatime). The NFS server also doesn't update atime on reading (well, sometimes); thus this information on
NFS-mounted file systems is not always true.
I would like to try to create a new file and get all 3 dates set to different values.
I don't know of any way to do that. You can change the atime and the mtime with touch later, after creation. Each touch will update ctime, since you update meta information about the file (see above).
HTH, Joachim
Thanks for the info. Based on the above, would the following alwayas be true -- ctime >= mtime >= atime ? Seems like it would. Greg Wallace
Greg Wallace wrote:
Based on the above, would the following alwayas be true --
ctime >= mtime >= atime ?
No, for two reasons: If a file is read, its atime is updated, but neither ctime nor mtime. Then the last relation is not true any more. One can set mtime and atime to arbitrary dates in the future. Then both relations are not true any more. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
On Wednesday, April 12, 2006 @ 7:46 PM, Joachim Schrod wrote:
Greg Wallace wrote:
Based on the above, would the following alwayas be true --
ctime >= mtime >= atime ?
No, for two reasons:
If a file is read, its atime is updated, but neither ctime nor mtime. Then the last relation is not true any more.
One can set mtime and atime to arbitrary dates in the future. Then both relations are not true any more.
Joachim
Did I get it backwards? I. e., is this true -- ctime <= mtime <= atime. ln other words, an mtime change ripples to atime and a ctime change ripples to ntime which ripples to atime? Put another way, you can change atime without affecting mtime or ctime. You can change mtime without affecting ctime, but atime will be affected. If you change ctime, then mtime and atime are affected. Would that be correct? Greg Wallace Greg Wallace
Leendert Meyer wrote:
No, but I didn't look for them very hard. ;P It wouldn't be too difficult to write a little script that checks every file on your system and reports the file(s) that have all 3 times different.
Please note that such a script won't be very sensible. Since every read access changes atime, the ``access time'', there will be very few files that have all 3 times the same. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
On Wednesday 12 April 2006 14:51, Joachim Schrod wrote:
Leendert Meyer wrote:
No, but I didn't look for them very hard. ;P It wouldn't be too difficult to write a little script that checks every file on your system and reports the file(s) that have all 3 times different.
Please note that such a script won't be very sensible.
Since every read access changes atime, the ``access time'', there will be very few files that have all 3 times the same.
Indeed, you're quite right! ;D I've never tought of that. It's a paradox: the very property that one wants to monitor is changed by the same action. Hmm, one would have to mount a filesystem read-only. I suppose then it would work. Cheers, Leen
Richard Bos wrote:
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily
Please don't take this email as a personal critic. Since you wrote most of this page, I thought you might be interested in feedback and proposals for improvement of this page. The warning after the tip to change the system time should be more explicit, IMNSHO. It is *never* a good idea to change system time just to create a file accordingly. Too many other services need continuous time. IMHO this should be marked as a "bad proposal" that might pop up and is listed on the page just to warn against it. I think that the stat example is better understandable if the stat command is without the -c option. Just calling stat outputs these times at the end; that's as easy to grasp for the user and easier to write. You might also want to include an example output on the page. To use find to output the ctime is rather obscure. IMO the ls command with option -lc is more appropriate, and this obvious solution (most people use ls to show meta-information of files) is missing on the page. It's not only said that the touch command does not work; that is definitively the case. There is no need to check. There ain't no POSIX or Linux function to set ctime; it's as simple as that. (My question about about another way, in a post some days ago, was rhetoric. I'm programming in UNIX for 25 years now, and my experience tells me: that's the way it is, sadly.) Your "Another Solution" section on the Wiki page is misleading. touch *always* updates ctime to the current timestamp, there is no way to avoid that. The sentence on the Wiki "touch -t only modifies acces-time and modify-time." reads as if this command would not change ctime, but it does. To wit: puma:tmp $ touch testfile puma:tmp $ stat testfile File: `testfile' Size: 0 Blocks: 0 IO Block: 8192 regular empty file Device: 17h/23d Inode: 623423 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1014/ schrod) Gid: ( 2000/ npc) Access: 2006-04-12 14:16:39.791001499 +0200 Modify: 2006-04-12 14:16:39.791001499 +0200 Change: 2006-04-12 14:16:39.791001499 +0200 puma:tmp $ touch -t 04110000 testfile puma:tmp $ stat testfile File: `testfile' Size: 0 Blocks: 0 IO Block: 8192 regular empty file Device: 17h/23d Inode: 623423 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1014/ schrod) Gid: ( 2000/ npc) Access: 2006-04-11 00:00:00.000000000 +0200 Modify: 2006-04-11 00:00:00.000000000 +0200 Change: 2006-04-12 14:17:11.612405346 +0200 See how the touch not only set atime and mtime, but also updated ctime to the current timestamp. That is not an issue with touch. The reason is the underlying POSIX function utime() (or utimes(), alternatively) that does that ctime update unconditionally; there's no way to avoid that. See http://www.opengroup.org/onlinepubs/009695399/functions/utime.html, the last paragraph of the DESCRIPTION section, where it is spelled out. Please note that the Linux man page of utime/utimes does not spell out that detail, but Linux implements the POSIX semantics as specified in the given link. Concerning the section "cron.daily drift": SUSE 9.2 and earlier had no drift, because it explicitly deleted the timestamp files at a given time with own cron jobs. I don't know about SUSE 9.3. I have not observed drift on SUSE 10.0, though analysis of the code leads to the suspicion that it might happen there. (I have to say that I liked the implementation of 9.2 better than the one of 10.0.) HTH, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
Op woensdag 12 april 2006 14:49, schreef Joachim Schrod:
Richard Bos wrote:
Have a look here: http://susewiki.org/index.php?title=Schedule_cron_daily
Please don't take this email as a personal critic. Since you wrote most of this page, I thought you might be interested in feedback and proposals for improvement of this page.
Thanks for the feedback. Please, put it in the wiki, that is what a wiki is for! Your information will make the page more valuable for others. No without your update, it remains the same...
The warning after the tip to change the system time should be more explicit, IMNSHO. It is *never* a good idea to change system time just to create a file accordingly. Too many other services need continuous time. IMHO this should be marked as a "bad proposal" that might pop up and is listed on the page just to warn against it.
I think that the stat example is better understandable if the stat command is without the -c option. Just calling stat outputs these times at the end; that's as easy to grasp for the user and easier to write. You might also want to include an example output on the page.
To use find to output the ctime is rather obscure. IMO the ls command with option -lc is more appropriate, and this obvious solution (most people use ls to show meta-information of files) is missing on the page.
It's not only said that the touch command does not work; that is definitively the case. There is no need to check. There ain't no POSIX or Linux function to set ctime; it's as simple as that. (My question about about another way, in a post some days ago, was rhetoric. I'm programming in UNIX for 25 years now, and my experience tells me: that's the way it is, sadly.)
Your "Another Solution" section on the Wiki page is misleading. touch *always* updates ctime to the current timestamp, there is no way to avoid that. The sentence on the Wiki "touch -t only modifies acces-time and modify-time." reads as if this command would not change ctime, but it does.
Check the 'history' of the page and you'll see, that someone else than me added that to the page.
To wit: puma:tmp $ touch testfile puma:tmp $ stat testfile File: `testfile' Size: 0 Blocks: 0 IO Block: 8192 regular empty file Device: 17h/23d Inode: 623423 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1014/ schrod) Gid: ( 2000/ npc) Access: 2006-04-12 14:16:39.791001499 +0200 Modify: 2006-04-12 14:16:39.791001499 +0200 Change: 2006-04-12 14:16:39.791001499 +0200 puma:tmp $ touch -t 04110000 testfile puma:tmp $ stat testfile File: `testfile' Size: 0 Blocks: 0 IO Block: 8192 regular empty file Device: 17h/23d Inode: 623423 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1014/ schrod) Gid: ( 2000/ npc) Access: 2006-04-11 00:00:00.000000000 +0200 Modify: 2006-04-11 00:00:00.000000000 +0200 Change: 2006-04-12 14:17:11.612405346 +0200
See how the touch not only set atime and mtime, but also updated ctime to the current timestamp.
That is not an issue with touch. The reason is the underlying POSIX function utime() (or utimes(), alternatively) that does that ctime update unconditionally; there's no way to avoid that. See http://www.opengroup.org/onlinepubs/009695399/functions/utime.html, the last paragraph of the DESCRIPTION section, where it is spelled out. Please note that the Linux man page of utime/utimes does not spell out that detail, but Linux implements the POSIX semantics as specified in the given link.
Concerning the section "cron.daily drift": SUSE 9.2 and earlier had no drift, because it explicitly deleted the timestamp files at a given time with own cron jobs. I don't know about SUSE 9.3. I have not observed drift on SUSE 10.0, though analysis of the code leads to the suspicion that it might happen there. (I have to say that I liked the implementation of 9.2 better than the one of 10.0.)
I reported the drift as bug to suse including a solution. The solution has been accepted and after that the daily scripts don't drift anymore... However, I don't remember the version. Thanks a lot for your information, it's highly appreciated, it would be great if add it to the wiki. -- Richard Bos Without a home the journey is endless
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-04-12 at 20:48 +0200, Richard Bos wrote:
I reported the drift as bug to suse including a solution. The solution has been accepted and after that the daily scripts don't drift anymore... However, I don't remember the version.
9.3 has it wrong. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEPYtqtTMYHG2NR9URAvQFAKCRHuf+XTsXf0h6ePAKJlRyrNdHRQCZAb6T KIE4MA1X8TEDFCulM2GIkTQ= =KJdh -----END PGP SIGNATURE-----
Greg Wallace wrote:
On Sunday, April 09, 2006 @ 2:50 PM, Joachim Schrod wrote:
By the way, the full formal definition of ctime is buried in the pit of the Single Unix Specification; where every function that changes the ctime value says so explicitly in its description. See http://www.opengroup.org/onlinepubs/009695399/toc.htm
I promise I'm not trying to steal this thread,
Subject changing is a good idea then. ;-)
What type of action changes the file's status change date (and would that also necessarily change the file's creation/modification date?)?
Everything that changes the file name or its content updates ctime, also mtime. One can set the mtime explicitly with utime() or utimes(), but not the ctime. In fact, utime() updates ctime itself. This means that ctime is the more reliable indicator when a file was changed the last time in any way than mtime. For example, if you unpack a tar or zip archive, or if you install an RPM, the files' mtime will get set as specified in the archive, but the ctimes are set to the timestamp of unpacking. For the precise information I posted the link above. Click on "Word" search, and search for "st_ctime" in the XSH section. Then all C functions appear that (may) update ctime. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-04-07 at 19:52 -0800, Scott Leighton wrote:
Scott Leighton wrote:
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
No, /etc/cron.d is monitored by cron, but /etc/cron.{daily,hourly,monthly} are not. Those are not monitored, nor cached; they are simply loaded or called when the time arrives for execution, by another script that is run by cron. There is no need to monitor a file that is not in crontab syntax nor contain timing information. To check this, I copied nimrodel:/etc/cron.daily/tetex to tetex2. No reload messages. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEOEYotTMYHG2NR9URAi3GAKCD4niaWOC5S04m+6gA8FJbn+09WQCgijnN wcehGqWWEpr3wU2faMNA7yA= =TlXw -----END PGP SIGNATURE-----
On Saturday 08 April 2006 4:24 pm, Carlos E. R. wrote:
The Friday 2006-04-07 at 19:52 -0800, Scott Leighton wrote:
Scott Leighton wrote:
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
No, /etc/cron.d is monitored by cron, but /etc/cron.{daily,hourly,monthly} are not. Those are not monitored, nor cached; they are simply loaded or called when the time arrives for execution, by another script that is run by cron. There is no need to monitor a file that is not in crontab syntax nor contain timing information.
To check this, I copied nimrodel:/etc/cron.daily/tetex to tetex2. No reload messages.
Good catch! I do all my stuff in /etc/cron.d so I really never tested /etc/cron.{daily,hourly,monthly}. Scott -- Pro tempore (pro tem.) POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
Scott Leighton wrote:
On Friday 07 April 2006 3:29 am, Joachim Schrod wrote:
Scott Leighton wrote:
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.
No, it is complete, as mentioned by Carlos. One addition to what he said, for the sake of searches in the archives:
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.
run-crons tests for the presence of lockfiles, it has nothing to do with the cached scripts that crond is dealing with.
SUSE 10.0, /usr/lib/cron/run-crons: From line 73 to line 100, lock files are deleted, as you write. Line 114-165 defines the shell function run-scripts that is called in line 187. Alas, /usr/lib/cron/run-crons runs the scripts from those directories, this is _not_ done by crond itself. That script also does this a bit more intelligently than crond with /etc/cron.d/*, actually; as it ignores obvious backup files and rpm files. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany
On Sunday 09 April 2006 12:58 pm, Joachim Schrod wrote:
Scott Leighton wrote:
On Friday 07 April 2006 3:29 am, Joachim Schrod wrote:
Scott Leighton wrote:
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.
No, it is complete, as mentioned by Carlos.
One addition to what he said, for the sake of searches in the archives:
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.
Correct, the man page doesn't reference checking the modtime on /etc/cron.d, which is monitored and it rightfully doesn't mention /etc/cron.{daily,hourly,weekly,monthly}, which are not monitored. We agree, Carlos set me straight on the different treatment, I was focused on /etc/cron.d where I was having the problem. Scott -- Risu inepto res ineptior nulla est POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-04-06 at 20:21 -0800, 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
We had that discussion some time ago here and reached the same conclussion. You could have saved time looking it up ;-) X-Message-Number-for-archive: 252521 Date: Sun, 06 Nov 2005 14:35:53 +0100 Subject: [SLE] Changes in cron.d-files are not detected automatically http://lists.suse.com/archive/suse-linux-e/2005-Nov/0732.html
The crontab program automatically takes care of updating the directory timestamp for /var/spool/cron/tabs if a user changes their tab with crontab -e.
Some editors, like vim, also change directory timestamps when you edit a file, so they have the effect of essentially acting like crontab -e would when used on a system cron file saved at /etc/cron*
Some editors cause the timestamp change, some don't. http://lists.suse.com/archive/suse-linux-e/2005-Nov/0951.html
My particular issue is that I've come to expect that the editor I am primarily using, mcedit, acts right and changes the directory timestamp. Unfortunately, it apparently doesn't always do so (which is a whole new issue) since it acts one way on my home system and a completely different way on my work system (I've compared the ~/.mc/ini files on both systems, they are identical, so I don't think it is a config issue, but I'm still looking).
Interesting. Compare the mcedit versions (rpm -q mc) (mcedit --version) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFENkNRtTMYHG2NR9URAtEtAJ4lYGHwWwDx6L+x+sX5MqzyNBk9ZgCfdbp/ 8uc1LjlyZWc/SX0c/BkDLTo= =ci9c -----END PGP SIGNATURE-----
On Friday 07 April 2006 3:47 am, Carlos E. R. wrote:
My particular issue is that I've come to expect that the editor I am primarily using, mcedit, acts right and changes the directory timestamp. Unfortunately, it apparently doesn't always do so (which is a whole new issue) since it acts one way on my home system and a completely different way on my work system (I've compared the ~/.mc/ini files on both systems, they are identical, so I don't think it is a config issue, but I'm still looking).
Interesting. Compare the mcedit versions (rpm -q mc) (mcedit --version)
I did, they are identical on both boxes. #mcedit --version GNU Midnight Commander 4.6.1-pre3 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, undelfs With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support Also tried diff'ing the various config files in /usr/share/mc and in ~/.mc and couldn't find anything different that seemed pertinent. On the 64 bit box, mcedit creates a softlink in the current directory for the file being edited, that apparently causes the directory timestamp to update. On the 32 bit box, no softlink is created and I have no idea at all why they act differently. I've resigned myself to simply doing a rccron restart. Scott -- Vescere bracis meis POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-04-07 at 19:39 -0800, Scott Leighton wrote:
Interesting. Compare the mcedit versions (rpm -q mc) (mcedit --version)
I did, they are identical on both boxes.
Perhaps the 64 bit version was compiled with a diferent option.
... Also tried diff'ing the various config files in /usr/share/mc and in ~/.mc and couldn't find anything different that seemed pertinent.
Anything about creating a backup file while editing?
On the 64 bit box, mcedit creates a softlink in the current directory for the file being edited, that apparently causes the directory timestamp to update. On the 32 bit box, no softlink is created and I have no idea at all why they act differently.
If it doesn't create a softlink it means it makes no backup of the file, but changes it in place. That method does not alter the directory, it does not create nor delete files. I think only the inode might change.
I've resigned myself to simply doing a rccron restart.
Simply edit it again wit a diferent editor, like joe (aka jstar aka jmacs aka rjoe aka jpico), and save. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEOEKitTMYHG2NR9URAmMNAJ9obOKsVLHhWlxil2XXHQ0SVKxVngCdF9u8 qfZMm7TGVEQFzg+pymL5lZo= =P2rI -----END PGP SIGNATURE-----
On Saturday 08 April 2006 4:09 pm, Carlos E. R. wrote:
The Friday 2006-04-07 at 19:39 -0800, Scott Leighton wrote:
Interesting. Compare the mcedit versions (rpm -q mc) (mcedit --version)
I did, they are identical on both boxes.
Perhaps the 64 bit version was compiled with a diferent option.
... Also tried diff'ing the various config files in /usr/share/mc and in ~/.mc and couldn't find anything different that seemed pertinent.
Anything about creating a backup file while editing?
There's a setting, 'editor_option_save_mode', but it is set to 0 on both systems.
On the 64 bit box, mcedit creates a softlink in the current directory for the file being edited, that apparently causes the directory timestamp to update. On the 32 bit box, no softlink is created and I have no idea at all why they act differently.
If it doesn't create a softlink it means it makes no backup of the file, but changes it in place. That method does not alter the directory, it does not create nor delete files. I think only the inode might change.
I've resigned myself to simply doing a rccron restart.
Simply edit it again wit a diferent editor, like joe (aka jstar aka jmacs aka rjoe aka jpico), and save.
I'm way too old and set in my ways to change my habits ;) My fingers automatically type mcedit when I'm on the commandline, no thinking involved at all. Scott -- Aegroto, dum anima est, spes esse dicitur POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.11.4-21.11-default x86_64 SuSE Linux 9.3 (x86-64)
I'm seeing the same kind of thing on a boxed 10.0 X86 system. Running crontab, which touches the files in /var/spool/cron, doesn't trigger a cron daemon reload. It does work on 10.0 AMD-64 boxes, however. Regards, Lew Wolfgang Scott Leighton wrote:
I'm running SUSE 9.3 on two machines, a 64 bit installation at home and a 32 bit installation at work. Both machines are up to date with all YOU updates and are configured similarly.
The work machine doesn't seem to be recognizing changes made to cron files in /etc/cron.d, that is, a RELOAD of the changed file never happens and doesn't show in the log. I basically have to rccron restart to get the cron daemon to use the new file.
The home machine does recognize changes, a RELOAD will take place within a minute or so after saving the changed file back to /etc/cron.d
I've checked ownership (root) and permissions (600) on both boxes, they are the same, so I'm looking for ideas on where to look next to figure out what is causing the work machine to not see the changes made to /etc/cron.d files.
Any ideas will be appreciated, I'm pretty much stumped right now.
Scott
participants (9)
-
Carlos E. R. -
Carlos E. R. -
Greg Wallace -
Joachim Schrod -
Leendert Meyer -
Lew Wolfgang -
Patrick Shanahan -
Richard Bos -
Scott Leighton