[Nut-upsdev] Re: NUT: Belkin Universal driver - modification to -k
behaviour
j T
hyvan_trant at hotmail.com
Tue May 16 21:34:26 UTC 2006
Hi Peter
>From: (Peter Selinger)
>To: (j T)
>CC: (NUT developers)
>Subject: Re: NUT: Belkin Universal driver - modification to -k behaviour
>Date: Tue, 16 May 2006 13:21:10 -0300 (ADT)
>
>thanks for the patch. This seems like a smart idea to me. I have to
>study your patch carefully though, to make sure it will do the right
>thing in all situations.
WRT the "any situation suitability" of the patch, I totally understand...
I've only tested it to make sure that it starts watching the UPS power level
when there's a power failure and that it brings the system back up if the
utility power is restored before the battery is depleted... and then only on
a single Fedora Core 5 system with an ancient AT powersupply.
>I guess your patch would eliminate the need for a custom shutdown
>script.
Yes, the patched-in "waitonshutdown" capability should eliminate the need
for customised shutdown scripting.
>If I understand correctly, modifications to the startup script would
>still be required to ensure the computer does not mount any disks in
>read/write mode until after the battery level is high enough to
>survive another outage.
QUERY
------
Do all UPSs bring the load straight back online as soon as the utility power
is restored, or is this a peculiarity of the Belkin Universals?
If its a Universal quirk, could you not set a preset amount of time between
utility power and load-on by using one of the timers that are used in the
original -k behaviour?
I'm afraid I'm majorly busy this week, so I doubt I'll have a chance to
experiment with this idea... if someone else has already played with it
though and it did not work, I'd appreciate knowing I'd be wasting my time!
--
I *was* hoping to also be able to make it unnecessary to modify the startup
scripting but I'm afraid I drew a bit of a blank as to how to do it, or more
specifically, how to get it to be run early enough in the startup scripting
for it to actually do what we want it to when we want without having to make
modifications to the scripts.
Making belkinunv wait for a decent battery state isn't difficult; it already
has the ability to do this as a response to a "-x wait=nn" command line, so
it shouldn't be difficult to call the belkin_wait() routine from the routine
that initialises the driver; it could even be configured to wait for a
specific batter level through ups.conf by setting a wait=nn value in there.
But that in itself isn't really a big help... On (say) a Fedora box, even if
you were to have the ups startup script as S00ups, it would still be run
after the drive mount operation, as this is performed by rc.sysinit (init's
first port of call when booting).
I suspect the reason that startup script modifications for the Universal are
necessary on Fedora is two fold:
1) There is no easy way to ensure that the "-x wait=nn" command-line *isn't*
used when trying to run a non-belkinunv driver...
2) running a NUT driver with flags and/or values it doesn't understand
results in seg faults (atleast it did when I accidentally tried to load the
original belkinunv driver with waitonshutdown=true set in ups.conf!!).
The only thing I can think of that would potentially fix the situation is
for NUT to distribute a script, say "/sbin/nut.init". This would include any
quirk modifications/safeguards required by any UPS.
A step detailing that the nut.init script should be added to the system init
script before mounting filesystems, etc. can then be added to the
installation/configuration instructions.
With a little luck, distributions that supply NUT (such as Fedora) will then
realise that it is not only a Good Idea(tm) to run nut.init before the drive
mount stuff, but that it is also safe to do so without risking segfaults,
etc.
And for people who are setting NUT up from source, it means they don't have
to make any major changes to their startup scripting, they just need to call
"/sbin/nut.init" and that would handle everything for them.
It may be necessary to provide some kind of utility program that can give
the nut.init script access to the configuration details for each UPS
configured for the system, as it think it would be necessary to know the
ups at host string and the driver it uses (and possibly others).
>I tried to forward your message to the nut-upsdev mailing list, but
>somehow this did not work. I have put the patch on the Alioth tracker
>instead at
>
>http://alioth.debian.org/tracker/index.php?func=detail&aid=303445&group_id=30602&atid=411544
Just to let you know that, as you suggested, I did subscribe to the
nut-upsdev list, and I have had copies of my messages delivered via the
list, as well as a couple of other ones (something about upsched if memory
serves... its been a long day though, so that's not guaranteed ;-) )...
anyway, the list does appear to be working...
Jo Turner
--
jT | mail to: hyvan_trant at hotmail.com
** | website: http://www.chiark.greenend.org.uk/~jsturner/
More information about the Nut-upsdev
mailing list