Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!sgi!vjs@rhyolite.SGI.COM
From: vjs@rhyolite.SGI.COM (Vernon Schryver)
Newsgroups: comp.mail.uucp
Subject: Re: su uucp in crontabs/root ?
Summary: confirmation please
Keywords: root uucp crontab su
Message-ID: <32031@sgi.SGI.COM>
Date: 4 May 89 16:53:28 GMT
References: <75@norsat.UUCP> <2008@egvideo.UUCP> <532@bilver.UUCP>
Sender: daemon@sgi.SGI.COM
Distribution: na
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 34

In article <532@bilver.UUCP>, bill@bilver.UUCP (bill vermillion) writes:
> ...
> "cron exmains the crontabs directory periodically to see if it has changed; if
> it has, cron reads it.  Thus it takes only a short while for entries to become
> effective"
> 
> That was a welcome change...

It would indeed be a welcome change to go back to the old behavior when
cron would regularly stat(2) the file /usr/lib/crontab.

However, a quick check of the SVR3.2 source suggests to me that cron
only calls dscan() from read_dirs(), which is only called from initialize(),
which is only called
  (1) at the beginning,
  (2) when time appears to have run backwards,
  (3) and when time appears to have jumped more than 120 seconds
	past the second when the next event was expected to finish.

What am I misunderstanding?

Checking the mtime of the directory would be useful, but not perfect,
since an aging hack is likely to `vi /usr/spool/cron/crontabs/root`,
and not bother to `touch /usr/spool/cron/crontabs`.  Thus, you would
probably want cron to stat(2) every file in /usr/spool/cron/crontabs.

A handy thing added to SGI's version of SVR3 cron is to have cron pay
attention to SIGHUP, closing and re-opening the log file.  This
allows the log to be rotated without the stupid console message.


Vernon Schryver
Silicon Graphics
vjs@sgi.com