[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