From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 26 19:36:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BDA1106564A; Sat, 26 Nov 2011 19:36:23 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3154A8FC14; Sat, 26 Nov 2011 19:36:22 +0000 (UTC) Received: by wwe5 with SMTP id 5so4170508wwe.31 for ; Sat, 26 Nov 2011 11:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=c6Fd92uzgXF0VXp1Ibc9MIyFjfIF2y2Pt6OhswvdiKM=; b=ozbHHX4prKYHLR3r5lEcCPgwY70Consd5L24jsCmARskUOYBARL3ABbLo5RA3Xxqxq 0NQv6+qXjpuNK13LRnjCunVZu5TsM5C6mvYWKyBOVRBiiJs8zr9aSeG+U9heMxVqK867 kNiPojfC+shRnaNNAe2CJ9/zaHBKs6ZokAUfo= Received: by 10.227.205.5 with SMTP id fo5mr1968394wbb.4.1322336181304; Sat, 26 Nov 2011 11:36:21 -0800 (PST) Received: from DataIX.net (ppp-21.232.dialinfree.com. [209.172.21.232]) by mx.google.com with ESMTPS id hq5sm12338598wib.7.2011.11.26.11.36.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Nov 2011 11:36:20 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pAQJa8iO003033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Nov 2011 14:36:08 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pAQJa3hN003032; Sat, 26 Nov 2011 14:36:03 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Sat, 26 Nov 2011 14:36:03 -0500 From: Jason Hellenthal To: Chris Rees Message-ID: <20111126193602.GA2368@DataIX.net> References: <20111125070241.GA7915@DataIX.net> <4ED00A68.4040606@kvr.at> <20111126051121.GA4628@DataIX.net> <20111126190030.GA58253@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: Cc: Christian Kastner , Michael Ross , freebsd-hackers@freebsd.org Subject: Re: cron(8) mis-feature with @reboot long after system startup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 19:36:23 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 26, 2011 at 07:05:00PM +0000, Chris Rees wrote: > On 26 November 2011 19:00, Jason Hellenthal wrote: > > On Sat, Nov 26, 2011 at 06:43:38AM +0100, Michael Ross wrote: > >> Am 26.11.2011, 06:11 Uhr, schrieb Jason Hellenthal : > >> > On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote: > >> >> Hi, > >> >> > >> >> On 2011-11-25 08:02, Jason Hellenthal wrote: > >> >> > So with that said... is there a way we could actually make this r= un > >> >> @reboot only ? > >> >> > >> >> Debian's cron[0] and Fedora's cronie[1] have solved this by touchin= g a > >> >> file on first startup and running @reboot only when this file does = not > >> >> yet exist. > >> >> > >> >> Note that while [0] may point to other patches that might be of int= erest > >> >> to FreeBSD, they are still WIP (as evident from the linked patch) a= s we > >> >> are still in the process of quiltifying our current code base. > >> >> > >> > > >> > While this sounds like a perfectly sane way to handle the problem at > >> > hand this also introduces a need to write some cleanup code to take = care > >> > of the file semantics. I think comparing daemon start times to the t= ime > >> > a system was booted or similiar would alleviate the need for all tha= t. > >> > Maybe a flag for @reboot "-s " seconds after boottime to al= low > >> > running @reboot jobs. And set the default to 3600 seconds. At least = this > >> > would allow adjustment for those startup processes that may take some > >> > considerable time before multiuser mode is entered. > >> > > >> > Just some thought. > >> > > >> > I really don't think we need to go the route of using files to store > >> > information when there is enough information available already via > >> > syscall's. > >> > >> If system startup were to be unusually delayed (dhcp or nfs trouble eg= ), > >> $time_period might have passed when cron starts, so there would have t= o be > >> some notifying mechanism for @reboot jobs not being run, and operator > >> action would be required. > >> > > > > I agree but also disagree. 1 hour or 3600 seconds is plenty of time to = wait for the "@reboot" extension scripts to fire. >=20 > Yes, and if I restart cron 30 minutes after boot, I'm screwed. >=20 Very true. But it would still be keeping its same behavior that it has had = for the last .... some odd years. Also it should be noted that my references to using time as way to figure o= ut if cron has been run @reboot only does have another fallback. If a syste= m is brought into single-user mode then you would obviously want the @reboo= t scripts to run again since essentially everything has been brought down s= imiliar to a reboot. what would be nice is if the init and kernel would keep kern.init.times and= create a syscall for thes so the time gets set when init goes mult-iuser. = Then at least there would be something real to compare to. --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJO0T+iAAoJEJBXh4mJ2FR+T8wH/RJJWMP77V67XWMIAvGJ0On5 Dw/qbLJkI7zKB1YiNHR6sknp7r7+7BT18OPYLFCnvUxaoYkO/Nzkv8UfHSGo3bTB KRzDbQTjRaasbWHqE6yTAJW1e2nwfJ/f93HLmLF5GfZKmptBATbmHeBPavov/Fz/ bZTJrkGEaAE+ZU+ifYrpbVfrdh2c75pg3T0EbEWT2F+QgPvkhcNxZnjwaolUOOfi 8mBNJGJk4NHRrXcUHzBDgnjWVNuRsXhdZORF8Mf6XLgVUJmQTWIUSMTougZiN+aK wucM/DZmiuGayqqGks1jeSWJyKWZWlK0CBZq0cuVOKmzVsn4Hbk2yREWi9TWQ8k= =py9R -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi--