8.1: Cron ignoring crontab updates

[patrick]

I recently upgraded a FreeBSD 7.0 system to 8.1-RELEASE (via
freebsd-update) and am experiencing the strangest cron problem I have
ever seen.

My cron jobs run, but if I make any changes to my crontab, cron does
not pick them up; it continues to operate based on the snapshot of
crontabs it loaded when cron was started up. If I restart cron
(/etc/rc.d/cron restart), the changes are then picked up, but again,
any subsequent changes are ignored. I don't see any issues with the
permissions, and when I edit a crontab, it says "crontab: installing
new crontab", and the /var/log/cron log shows BEGIN EDIT, REPLACE, and
END EDIT.

I'm somewhat at a loss to figure out where the disconnect is, and it's
impractical for me to have to restart cron any time any user updates
their crontab. Has anyone come across this?

Patrick

[Chris Rees]

You have to SIGHUP cron, not restart it.

# killall -HUP cron

Chris

--------

Sorry for top-posting, Android won't let me quote, but K-9 can't yet do
threading.

On 2 Sep 2010 21:11, "patrick" <***@gmail.com> wrote:

I recently upgraded a FreeBSD 7.0 system to 8.1-RELEASE (via
freebsd-update) and am experiencing the strangest cron problem I have
ever seen.

My cron jobs run, but if I make any changes to my crontab, cron does
not pick them up; it continues to operate based on the snapshot of
crontabs it loaded when cron was started up. If I restart cron
(/etc/rc.d/cron restart), the changes are then picked up, but again,
any subsequent changes are ignored. I don't see any issues with the
permissions, and when I edit a crontab, it says "crontab: installing
new crontab", and the /var/log/cron log shows BEGIN EDIT, REPLACE, and
END EDIT.

I'm somewhat at a loss to figure out where the disconnect is, and it's
impractical for me to have to restart cron any time any user updates
their crontab. Has anyone come across this?

Patrick
_______________________________________________
freebsd-***@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-***@freebsd.org"

[p***@pluto.rain.com]

Post by Chris Rees
You have to SIGHUP cron, not restart it.
# killall -HUP cron

Isn't crontab(1) supposed to do that, without separate intervention?

Post by Chris Rees
I recently upgraded a FreeBSD 7.0 system to 8.1-RELEASE (via
freebsd-update) and am experiencing the strangest cron problem
I have ever seen.
My cron jobs run, but if I make any changes to my crontab,
cron does not pick them up; it continues to operate based on
the snapshot of crontabs it loaded when cron was started up ...
Has anyone come across this?

Yes, so long ago I no longer remember which Unix flavor it was on.
Could have been SunOs 3.5 or 4.x, some version of Solaris, UnixWare,
or even FreeBSD 4.x.

[Arthur Chance]

Post by p***@pluto.rain.com

Post by Chris Rees
You have to SIGHUP cron, not restart it.
# killall -HUP cron

Isn't crontab(1) supposed to do that, without separate intervention?

From man cron

Post by p***@pluto.rain.com
Additionally, cron checks each minute to see if its spool directory's
modification time (or the modification time on /etc/crontab) has changed,
and if it has, cron will then examine the modification time 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 modification time of the spool directory whenever it
changes a crontab.

From the original post crontab seems to be working, so all I can suggest
is to "ls -ld /var/cron/tabs" before and after using crontab -e and see
if the modtime is being changed correctly.

[patrick]

Yes, it's definitely updating:

[***@juno /var/cron/tabs]# ls -ald /var/cron/tabs
drwx------ 2 root wheel 512 Sep 2 12:49 /var/cron/tabs

And after editing my crontab:

[***@juno /var/cron/tabs]# ls -ald /var/cron/tabs
drwx------ 2 root wheel 512 Sep 3 10:25 /var/cron/tabs

I've been using FreeBSD since version 4, and this has never once been
an issue, nor is this an issue on a system with a fresh install of
8.1.

Patrick

Post by Arthur Chance

Post by p***@pluto.rain.com

Post by Chris Rees
You have to SIGHUP cron, not restart it.
# killall -HUP cron

Isn't crontab(1) supposed to do that, without separate intervention?

From man cron

Post by p***@pluto.rain.com
    Additionally, cron checks each minute to see if its spool directory's
    modification time (or the modification time on /etc/crontab) has
changed,
    and if it has, cron will then examine the modification time 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 modification time of the spool directory whenever
it
    changes a crontab.

From the original post crontab seems to be working, so all I can suggest
is to "ls -ld /var/cron/tabs" before and after using crontab -e and see
if the modtime is being changed correctly.

[p***@pluto.rain.com]

Post by Arthur Chance

Post by p***@pluto.rain.com

Post by Chris Rees
You have to SIGHUP cron, not restart it.
# killall -HUP cron

Isn't crontab(1) supposed to do that, without separate
intervention?

From man cron

Post by p***@pluto.rain.com
Additionally, cron checks each minute to see if its spool
directory's modification time (or the modification time on
/etc/crontab) has changed, and if it has, cron will then
examine the modification time 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 modification time of the
spool directory whenever it changes a crontab.

OK, I had the mechanism wrong. The main point is, it should not
require manual intervention by an administrator to get cron(8) to
notice when crontab(1) has revised a crontab. The one thing I can
think of, short of a bug, is that a change made less than 1 minute
before the newly-added or -removed event might not be noticed in
time.