[Nut-upsuser] Debugging problem AFTER the failure?

[Tuc at T-B-O-H.NET]

> 
> 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).
>
	I log debug and higher to a "spool" file on the machine running NUT,
and all I see is :

Jul 30 10:45:08 valhalla openvpn[1307]: Data Channel Decrypt: Cipher 'RC2-CBC' i
nitialized with 128 bit key
Jul 30 10:45:08 valhalla openvpn[1307]: Data Channel Decrypt: Using 160 bit mess
age hash 'SHA1' for HMAC authentication
Jul 30 10:45:08 valhalla openvpn[1307]: Control Channel: TLSv1, cipher TLSv1/SSL
v3 DHE-RSA-AES256-SHA, 1024 bit RSA
Jul 30 11:06:31 valhalla syslogd: restart
Jul 30 11:06:31 valhalla syslogd: kernel boot file is /boot/kernel/kernel
Jul 30 11:06:31 valhalla kernel: Copyright (c) 1992-2008 The FreeBSD Project.


	My "ups.log" file just has :

20080730 104304 NA NA NA [OL] NA NA
20080730 110858 NA NA NA [OL] NA NA

	So it really doesn't tell me much.
> 
> >        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?
>
	I think as of February this year it did ( Last time I did a
test of it). 
> 
> 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.
>
	I'll probably have to cut down the time between upslog runs. The
UPS only lasted a little over 3 minutes last time. 
>
> 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.
> 
	Unfortunately this might have to wait until October. Its an 11
hour drive, pick up a jeep, and then almost 2 hours including driving on
the edge of the Atlantic Ocean (No road, reason for 4WD jeep) for a bit
to get to the site. 

	I was hoping to find proof that NUT started to do its thing, but
the UPS gave up sooner than expected. 

	Thanks, Tuc