From owner-freebsd-hackers Fri Feb 6 08:55:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA11338 for hackers-outgoing; Fri, 6 Feb 1998 08:55:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from callisto.fortean.com (callisto.fortean.com [209.42.194.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA11145 for ; Fri, 6 Feb 1998 08:54:53 -0800 (PST) (envelope-from walter@fortean.com) Received: from localhost (walter@localhost) by callisto.fortean.com (8.8.8/8.8.5) with SMTP id LAA22795; Fri, 6 Feb 1998 11:53:21 -0500 (EST) X-Authentication-Warning: callisto.fortean.com: walter owned process doing -bs Date: Fri, 6 Feb 1998 11:53:21 -0500 (EST) From: "Bruce M. Walter" Reply-To: "Bruce M. Walter" To: John Fieber , Mike Smith cc: hackers@FreeBSD.ORG Subject: Re: Powering off the system/UPS In-Reply-To: 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 X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" > Okay, I'm seeing the point (I think). You want to shutdown the > OS, *then* tell the UPS to shut down. I suppose that is > reasonable, since it at least gives the illusion of guaranteed > cleanup as opposed to telling the UPS "shutdown in 60 seconds" > and then calling halt(8) and hoping it can do its thing before > the UPS shuts off. Yes, and what's more is that the delayed UPS shutdown is a 'feature' of smarter UPS models... The APC BackUPS models only have immediate inverter shutdown :( > [I say "illusion" because if the time between a low battery > warning and a dead battery is less than your halt(8) time, you > are SOL either way. With a sufficiently smart and powerful UPS, > you should be able to avoid such situations though.] My empirical testing shows that at least the TrippLite and APC dumb UPS models pull the low battery trigger about 2-3 minutes before failure. This seems sufficient even for my big nasty machines, but user milage may vary. I'm working on reorganizing the kernel code to allow for this right now... Here's what I'm attempting as per Mike's suggestions: 1) There will be another queue, tenatively called 'SHUTDOWN_PRE_HALT' which will run after SHUTDOWN_POST_SYNC and before an actual reboot/halt. 2) I will add a new interface routine and support defines: #define SHUTDOWN_PRI_MIN 1 #define SHUTDOWN_PRI_MAX 20 #define SHUTDOWN_PRI_DEFAULT 10 int pri_at_shutdown(bootlist_fn func, void *arg, int when, int priority); which will add items to the shutdown queues with the specified priority. at_shutdown will remain the same and will add its callouts to the queues at a priority of SHUTDOWN_PRI_DEFAULT. rm_at_shutdown will also remain the same and will work on callouts added by either function. Callouts with the same priorities will be ordered LIFO. I'd love to hear any comments/suggestions from the peanut gallery. - Bruce ======================================================================== || Bruce M. Walter || 107 Timber Hollow Court #335 || || Senior Network Consultant || Chapel Hill, NC 27514 || || Fortean Technologies, Inc. || Tel: 919-967-4766 || || Information Technology Consultants || Fax: 919-967-4395 || ======================================================================== || BSD Unix -- It's not just a job, it's a way of life! || ========================================================================