[Nut-upsuser] Debugging problem AFTER the failure?

Charles Lepple clepple at gmail.com
Thu Jul 31 03:05:53 UTC 2008

On Wed, Jul 30, 2008 at 1:32 PM, Tuc at T-B-O-H.NET <ml at t-b-o-h.net> wrote:
> Hi,
>        Is there any way to debug a failure of NUT to shut a machine down
> AFTER the even occurs? (Be it a config issue {Though the standard "It
> hasn't changed since install" applies}, or a UPS failure, or a program
> failure).

The first place to start is your log files (syslog).

>        Its showing up (after reboot) as :
> valhalla# upsc robanton at localhost
> driver.name: genericups
> driver.parameter.pollinterval: 2
> driver.parameter.port: /dev/cuad1
> driver.parameter.upstype: 21
> driver.version: 2.2.1
> driver.version.internal: 1.33
> ups.mfr: Generic
> ups.model: Generic RUPS 2000
> ups.status: OL

Have you already checked to see if this upstype sends the proper
status signals for your UPS?

If you have the luxury of doing some off-line testing, you might want
to power the computer from another UPS or wall outlet for testing.

Monitor upsc as you check to see if the status transitions between OL
and OB when you cut power to the UPS. You could also use the upslog
command to monitor status, although most of the fields are geared
towards smart-protocol UPSes.

If you feel up to draining the battery, try that, and be sure that you
see a status of LB when the UPS indicates that the battery is
depleted. If upsmon is still running, it should begin to shut the
system down at this point.

If you trust that the LB signal is being recognized, you can fake a
shutdown with the 'upsmon -c fsd' command.

- Charles Lepple

More information about the Nut-upsuser mailing list