-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-11-07 at 02:08 +0100, Joachim Schrod wrote:

Yeah, I checked the man page, too. But I don't think that the paragraph above is concerned with /etc/cron.d at all -- it tells only about the spool files (in /var/spool/cron/tabs that are managed by crontab(1)) and /etc/crontab. I was not successful in finding any documentation about the supposed behavior of /etc/cron.d files at all.

And if the intention is that `cron need not be restarted whenever a crontab file is modified', that intention is not successfully implemented for cron.d entries.

Or do I miss something that's significant in the paragraph above? Please advise.

Perhaps. The previous paragraph to that one says: Cron searches /var/spool/cron for crontab files which are named after accounts in /etc/passwd; crontabs found are loaded into memory. Cron also searches for /etc/crontab and the files in the /etc/cron.d direc- tory, which are in a different format (see crontab(5)). Cron then wakes up every minute, exam- ining all stored crontabs, checking each command to see if it should be run in the current minute. When executing commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists). - From that I interpret that '/etc/cron.d' is also considered a "spool" directory. It is not explictly said, but I think that is the idea. It is directory of crontab files, so it is handled the same way, as explained in the next paragraph: Additionally, cron checks each minute to see if its spool directory's modtime (or the modtime on /etc/crontab) has changed, and if it has, cron will then examine the modtime on all crontabs and reload those which have changed. Thus cron need not be restarted whenever a crontab file is modified. Note that the Crontab(1) command updates the modtime of the spool directory whenever it changes a crontab. I think the doc writer just forgot to specify both directories. Note that it is faster to check the modtimes of two directories and one file, than all the modtimes of each file in both directories, as this is done every minute, and there could potentially be hundred of individual files there. It would not make sense. So the intention is that you edit any file there, then touch the directory. The program "crontab -e" does just that, but it only works for editing user files, I didn't see an option to edit cron.d/ files. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDbrgrtTMYHG2NR9URAlCEAJ9FXvlRhkOeVgxBO5vNi3hHvtaXPwCfbClv PxaHTjKZ3LhITiVpG4lqozM= =ZIQP -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-11-07 at 11:44 +0100, Per Jessen wrote:

I use a number of entries in /etc/cron.d/ but I've never had to touch the directory to get them accepted.

With some editors the modtime of the dir changes, and with some it doesn't.

Here I've just changed the file /etc/cron.d/spamchek and less than 60seconds later : (from /var/log/messages)

Nov 7 11:41:00 aluminium /usr/sbin/cron[1015]: (*system*spamchek) RELOAD (/etc/cron.d/spamchek)

I just did the same, with mcedit, and it did not... nimrodel:~ # l /etc/cron.d/ total 20 drwxr-xr-x 2 root root 4096 Oct 24 03:11 ./ drwxr-xr-x 97 root root 8192 Nov 7 01:13 ../ -rw------- 1 root root 577 Oct 16 03:17 seccheck -rw-r--r-- 1 root root 120 Mar 19 2005 vnstat nimrodel:~ # mcedit /etc/cron.d/vnstat nimrodel:~ # l /etc/cron.d/ total 20 drwxr-xr-x 2 root root 4096 Oct 24 03:11 ./ <--- no xhg drwxr-xr-x 97 root root 8192 Nov 7 01:13 ../ -rw------- 1 root root 577 Oct 16 03:17 seccheck -rw-r--r-- 1 root root 120 Nov 7 15:28 vnstat <--- Nov 7 15:30:01 nimrodel /usr/sbin/cron[21674]: (cer) CMD (/home/cer/bin/avisar_hablando time) (just a crontab job run) Now I try again with jstar (alias joe): nimrodel:~ # jstar /etc/cron.d/vnstat nimrodel:~ # l /etc/cron.d/ total 24 drwxr-xr-x 2 root root 4096 Nov 7 15:31 ./ <---- drwxr-xr-x 97 root root 8192 Nov 7 01:13 ../ - -rw------- 1 root root 577 Oct 16 03:17 seccheck - -rw-r--r-- 1 root root 120 Nov 7 15:31 vnstat <---- - -rw-r--r-- 1 root root 120 Nov 7 15:31 vnstat~ See the date of the directory changed. Now I do get cron reload: Nov 7 15:32:01 nimrodel /usr/sbin/cron[8624]: (*system*) RELOAD (/etc/cron.d/vnstat) See? The modtime of the /etc/cron.d/ directory has to change, or a reload will not occur. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDb2agtTMYHG2NR9URArI6AJ9pVRHCvQ/zOf5FzPJD7d9oF8r2eQCdGPIb 1s9R+vEyAVhXFgDVHUNp2+U= =NzFH -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-11-07 at 17:30 -0500, Patrick Shanahan wrote:

...

I just did the same, with mcedit, and it did not...

I believe that this would indicate that mcedit was seriously brokkken, ie: it does not provide the _expected_ results.

I don't know, it could be a feature. I don't really know why editing a file must alter the modify time of the directory where it resides. I'm not clear on this. Perhaps jstar affects the directory time because it creates a temporary file and renames the backup, whereas mcedit doesn't, working on the main file and overwrites it in place. Notice that the man cron(8) page mentions that "the Crontab(1) command updates the modtime of the spool directory whenever it changes a crontab", so that perhaps that is not what every editor does. No, I think it is a side effect of how each editor works, not a bug of any of them. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDcAGstTMYHG2NR9URApB1AKCBGdLIRt30GCrNsR9nsWgRy/gPUQCffMnT oKM9SzbP02F5N3PY6W1bil0= =PiP+ -----END PGP SIGNATURE-----

On Tue, 2005-11-08 at 00:19, Joachim Schrod wrote: [...]

Ooh? Since when is editing a file an operation that changes a directory? I would _not_ expect this to happen. Please note that vi does not update the directory timestamp either, and that's the default Unix editor (well, besides ed... :-)

Editing a file with vim (the default vi in 9.1) does indeed change the timestamp for the directory in which it resides. I did the following: jcunning@jlc:~> mkdir testdir jcunning@jlc:~> l -d testdir drwxr-xr-x 2 jcunning users 48 2005-11-08 20:32 testdir// jcunning@jlc:~> l -d refdir/ drwxrwxrwx 3 root root 72 2002-12-31 10:41 refdir// jcunning@jlc:~> touch -r refdir testdir/ jcunning@jlc:~> l -d testdir/ drwxr-xr-x 2 jcunning users 48 2002-12-31 10:41 testdir// jcunning@jlc:~> cd testdir jcunning@jlc:~/testdir> ls -CF ~ >dirlist jcunning@jlc:~/testdir> l total 13 drwxr-xr-x 2 jcunning users 72 2005-11-08 20:33 ./ drwxr-xr-x 94 jcunning users 8664 2005-11-08 20:32 ../ -rw-r--r-- 1 jcunning users 3005 2005-11-08 20:33 dirlist jcunning@jlc:~> touch -r refdir ~/testdir/ jcunning@jlc:~/testdir> l total 13 drwxr-xr-x 2 jcunning users 72 2002-12-31 10:41 ./ drwxr-xr-x 94 jcunning users 8664 2005-11-08 20:32 ../ -rw-r--r-- 1 jcunning users 3005 2005-11-08 20:33 dirlist jcunning@jlc:~/testdir> vi dirlist jcunning@jlc:~/testdir> l total 13 drwxr-xr-x 2 jcunning users 72 2005-11-08 20:34 ./ drwxr-xr-x 94 jcunning users 8664 2005-11-08 20:34 ../ -rw-r--r-- 1 jcunning users 2987 2005-11-08 20:34 dirlist Both the act of creating a file for the first time and editing it to delete a line changed the timestamp for the directory containing the file. -- Jim Cunning <jcunning@cunning.ods.org>