From owner-freebsd-hackers Sat Jan 13 14:18:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 321D937B404 for ; Sat, 13 Jan 2001 14:17:59 -0800 (PST) Received: (from uucp@localhost) by ns.internet.dk (8.11.1/8.11.1) with UUCP id f0DMHgb53733; Sat, 13 Jan 2001 23:17:42 +0100 (CET) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.11.1/8.11.0) with ESMTP id f0DMHQi49150; Sat, 13 Jan 2001 23:17:30 +0100 (CET) (envelope-from leifn@neland.dk) Date: Sat, 13 Jan 2001 23:17:26 +0100 (CET) From: Leif Neland To: Gerhard Sittig Cc: Greg Black , Doug Barton , freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) In-Reply-To: <20010113160917.Q253@speedy.gsinet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > One of the things that would need to be documented is what will > > happen to the new algorithm in the situation where cron is > > stopped and re-started during one of the time periods that gets > > repeated. > > Oh, you bring up an absolutely new datapoint it seems! Since all > the information vixie cron (in its original form as well as the > OpenBSD variant) keeps its state in is held in memory (the time > it went to sleep, the time it expects to wake up again, the time > it is collecting jobs for -- usually somewhere between the time > it went to sleep and the time it woke up at, catching up towards > the current time) it wouldn't know that it does repeat an hour it > just has passed few minutes ago in case there's been a restart in > between. > Oh no. If this "clock-slewing" was implemented, I'd expect killing and restarting cron be a way to forget everything which had happened. I.e. if I wanted to test a schedule, I might want to stop cron, reset time and start cron again. Cron usually doesn't die by itself. If it gets killed, it is usually for a reason. Don't complicate this proposed change with also having to add persistance over a kill and restart. Does anacron handle this DST issue better? Could it be added to ports if so, and a knob NO_CRON in make.conf? Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message