On Tue, Jan 25, 2005 at 09:49:27PM -0500, James Pifer wrote:
> > By any chance is there anything in /etc/cron.d/ directory? My
> > understanding is that those files are appended to /etc/crontab....
> >
> > Also, are there any user crontab files? would be found
> > in /var/spool/cron/
> >
> > For me, both of those directories are currently empty.
> >
> > One other stab in the dark, could this be one of those SELinux things?
> > Don't know enough yet to tell you how to temporarily turn off SELinux to
> > see if that is blocking it from starting/running....
SELinux would leave tracks in /var/log/messages.
It is also easy to turn on and off on a live system
to test the theory.
> > Also, I know you checked /var/log/cron earlier, but what about the
> > regular /var/log/messages?
>
> I'm not sure exactly what fixed this, but since about 5 hours ago it has
> been working. Can't remember the last thing I did, but it seems to be
> around the time someone said it was a permissions problem. I changed
> permissions and updated crontab slightly, then restarted crond.
It might be worth a look at the source.
What I think happened.....
If you change the permissions but do not update the modify flag
(see the man page for stat) then it can make sense that you
had to do two things. First permissions then update
the file so it has a new modify date-time stamp.
It is important to use the expected tools with cron.
Tools 'could have' ensured that permissions started out
correctly.
su - # use "su - " not "su "
id # check your ID.
crontab -e # edit
crontab -l # list
crontab file # submit file
Of interest cron on FC2 and FC3 works slightly different than historic
cron. In part this is to make the use as a desktop simpler. The
historic view is that a box ran 24x7 for the most part and that cron
started house keeping tasks would run as expected when the box was
booted for a couple hours.
Other folk with cron troubles should RTFM and Double check the allow
and deny config files (No one mentioned these that I saw).
>From the cron man page:
"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."
--
T o m M i t c h e l l
spam unwanted email.
SPAM, good eats, and a trademark of Hormel Foods.
