Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!uunet!pilchuck!dataio!fnx!del From: del@fnx.UUCP (Dag Erik Lindberg) Newsgroups: alt.sources.d Subject: Re: UPS monitor daemon part 1 of 1 Message-ID: <958@fnx.UUCP> Date: 23 Apr 91 19:28:59 GMT References: <1991Apr03.095011.9609@pilikia.pegasus.com> <1991Apr11.155416.28426@eci386.uucp> Organization: I/Ovations Kirkland, WA Lines: 62 In article <1991Apr11.155416.28426@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >In article <1991Apr03.095011.9609@pilikia.pegasus.com> root@pilikia.pegasus.com (Art Neilson) writes: >> The UPS monitor daemon or "upsd" watches the serial port >> connected to an UPS and will perform an unattended shutdown >> of the system if the UPS is on battery longer than a specified >> number of minutes. This software does not seem to deal with the following case: - Assume a UPS that lasts approximately 20 minutes on battery. - I set the daemon to shut the system down at 15 minutes. - Now, assume a power outage of 19 minutes duration. - At 15 minutes the system starts to shut down. - At 18 minutes the system is sitting at the "Press any key to reboot" - At 19 minutes the power returns. - We now have steady state with: a) Line power restored. b) Batteries are charging c) The system is waiting indefinitely for human intervention. This is unacceptable to me. It would seem the only acceptable solution would require MCU control including the ability to actually shut off line power to the system after a pre-determined delay to allow orderly shutdown, regardless of whether line power has been restored or not. Then, if line power *has* been restored, power up the system again. > >Neat-oh. How about a feature that can calculate the total time down >and the average charging time, and thus be able to figure out how long >the battery will last? I've seen this in a couple of commercial pgms. As someone pointed out, to really know how the battery is doing is difficult without analog monitoring of the VIN of the charging system. I don't think that would be much of a problem though, as you could easily build in big enough fudge factors to have the whole thing work, and the idea is an excellent one. >> X The -c cmd option specifies the full pathname of the command >> X to be executed to shut down the system. This command must >> X be enclosed in quotes if it consists of 2 or more words. > >A more elegant solution for System V is to just sent a SIGPWR to init, >i.e. kill(1, SIGPWR); and have your inittab configured correctly to >"do the right thing" with powerfail (and/or powerwait) entries. Why >waste all that code which was put there for just this feature? WRONG!!! This may be good enough for a single user workstation, but any multi-user system *MUST* warn users of impending doom to allow them to save their work, shut down whatever they are doing, and exit in a way that will allow them to resume work as quickly as possible when power is restored. Don't assume that everyone will be aware power went out on the system, they could be in a different building, or even another city. > >/etc/shutdown scripts are for human users, and can vary widely -- some >even ask for confirmation! Not something the average daemon can answer! So don't use the supplied shutdown script. Modify it, or write another. -- del AKA Erik Lindberg uunet!pilchuck!fnx!del Who is John Galt?