[Nut-upsdev] [nut-commits] svn commit r1376 - in trunk: . server

[Arnaud Quette]

2008/3/27, Arjen de Korte <nut+devel at de-korte.org>:
> > proof reading of NEWS and UPGRADING are welcome.
>
>
> One thing that popped up, is how to test the shutdown of the usbhid-ups
>  driver. Calling 'usbhid-ups -k' (as listed now) won't work, since the
>  driver will need to know which device to shutdown (the -a option is not
>  optional). In order not to accidentally shutdown a UPS that is powering a
>  live system, I would recommend to use 'upsmon -c fsd' here. This not only
>  makes sure that the system is shutdown properly before telling the UPS to
>  switch off, but also verifies that this late in the halt sequence we're
>  still able to talk to the UPS.

well, though you're right about the missing "-a", the aim of this note
was more a unit test: only test the UPS shutoff, not the whole
shutdown sequence. But that's also right that I've mentioned
"shutdown" and not "shutoff" in UPGRADING... Amended in r1401.

> If memory serves, there were some issues in
>  that area (reported by Peter Selinger) a while ago. On some systems, you
>  may need to run 'upsdrvctl shutdown' as root, since hotplug/udev support
>  may not be available anymore at that time (I know it is available on my
>  openSUSE system though).

I don't recall the whole thread (linked to r1277 iirc), but you're
right about calling upsmon...  Though in unit testing, we (should and
do) recommend to put only dumb loads.

Anyway, another issue that can be faced here is the missing libusb
since we're linked on the shared version. If the /usr partition is
already umounted, then we're stuck! That's a long standing issue in my
mind: sending early a delayed shutoff command (with the problem of the
dumb / instant off units), or lately (with the above mentioned issue).
Until now, I dealt with that on Debian by keeping the late shutoff,
and putting drivers and libusb in /lib.
Not the best, but the simplest.

A quick solution to Peter's above mentioned problem might be to drop
root privs when called for shutoff (ie not call become_user() in
drivers/main.c if do_forceshutdown is true)...

>  [...]
>
>
>  > Do you still hold some changes?
>
>
> Only one that I would like to see in nut-2.2.2. If no pollinterval is
>  specified, the netxml-ups driver should default to something like 5-10
>  seconds, to prevent people from shooting themselves in the foot (the older
>  NMC's might not like to be polled with 2 seconds intervals).
>
>  The recent server updates should *not* be in nut-2.2.2 until we're more
>  sure about the portability of the poll() function. It is in POSIX, but
>  marked as an X/Open System Interfaces Extension, so I have no idea if this
>  is portable to all the platforms/systems we support. I think it is best to
>  keep it in the trunk for a while (directing people there that need > 1024
>  clients monitoring a single server) to see if we get any complaints in
>  that area (might be something to include in nut-2.4).
>
>  I'm planning an update to the 'net_read()' function in the upsclient
>  library to allow it to read more data than it needs and return the
>  remainder in subsequent calls for that connection. For example, it would
>  read
>
>         WHATEVER\nIS IN THE\nBUF
>
>  from the server, return "WHATEVER" in the first call and "IS IN THE" on
>  the second call (without reading from the server) and prepend "BUF" to the
>  next read from the server (while repeating the process). We'll be fine
>  without this in nut-2.2.2, so we shouldn't wait with releasing it until I
>  had the time to code this.

agreed with all the above. I let you do the netxml-ups change for the
pollinterval. Then ping me back so that I can throw out -pre1...

Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/