Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
Re: [SLE] cron not recognizing changes to /etc/cron.d files [SOLVED]
  • From: Joachim Schrod <jschrod@xxxxxxx>
  • Date: Wed, 12 Apr 2006 14:49:36 +0200
  • Message-id: <443CF760.2000909@xxxxxxx>
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@xxxxxxx
Roedermark, Germany

< Previous Next >
Follow Ups