NetBSD Problem Report #46219

From www@NetBSD.org  Sun Mar 18 05:58:48 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 0E20863BEEC
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 18 Mar 2012 05:58:48 +0000 (UTC)
Message-Id: <20120318055847.4918C63B946@www.NetBSD.org>
Date: Sun, 18 Mar 2012 05:58:47 +0000 (UTC)
From: mayuresh@acm.org
Reply-To: mayuresh@acm.org
To: gnats-bugs@NetBSD.org
Subject: crontab changes do not take effect on the following minute
X-Send-Pr-Version: www-1.0

>Number:         46219
>Category:       bin
>Synopsis:       crontab changes do not take effect on the following minute
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 18 06:00:00 +0000 2012
>Last-Modified:  Sun Mar 18 08:00:03 +0000 2012
>Originator:     Mayuresh
>Release:        6.0_BETA
>Organization:
>Environment:
NetBSD laptop 6.0_BETA NetBSD 6.0_BETA (GENERIC) i386
>Description:
It is observed that crontab changes do not take effect on the immediate following minute.
>How-To-Repeat:
Set a job expected to run on following minute using crontab -e

e.g.

* * * * * date

Expect the command's output to be mailed to you on following minute. However it comes only on the subsequent minute.

Similarly if you delete this cron job, you'd expect it to not run on immediate following minute, but it does and stops only on subsequent minute.
>Fix:
Don't know.

>Audit-Trail:
From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/46219: crontab changes do not take effect on the following
 minute
Date: Sun, 18 Mar 2012 03:59:04 -0400

 On Sun, 18 Mar 2012 06:00:01 +0000 (UTC)
 mayuresh@acm.org wrote:

 > >Fix:
 > Don't know.

 Hmm after quickly checking the cron code, it seems that if we wanted
 cron(8) to immediately act upon a user change event, crontab(1) would
 have to kill the daemon with SIGHUP (I'm not sure poke_daemon() now
 does anything useful; since crontab(1) is setuid root, it probably
 could do this), or the daemon would have to use kevent polling with
 file modification notification.  What's interesting is that
 poke_daemon() seems to assume that this is what cron(8) should do,
 because what that function does is update the file time stamp...
 -- 
 Matt

Home	PR Database Search