Nut upsuser - Aug 2015 - occassional problem wtih upslog and apc ups units via snmp ... [NA] status

Os is redhat enterprise, kernel 2.6.18-164.2.1.e15
NUT is apparently 2.4.1
It was installed by tar.

Monitoring a lot of apc UPS units-mostly Smart-UPS of various flavors, also a
Silcon DP380E.

Normally works just fine...  "upslog" writes status log every 30
seconds with various parameters..

Every so often, one of the UPS units has a log entry of:

20150812+035542+NA+NA+NA+[NA]+NA+NA+NA

When it normally looks like:

20150813+114309+100.00+115.00+39.00+[OL]+25.00+60.00+1020.00

What does it mean when it  puts NA in the log file?

Recently we had an incident when all of our UPS units, (around 71 of them) got 2
NA records, all at about the same time...we are trying to figure out root cause.


Any ideas on what may cause this kind of behavior?

Thanks.
-Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150813/08ee34c5/attachment.html>

On Aug 13, 2015, at 12:45 PM, Bob Brown <bbrown at harpercollege.edu>
wrote:
> 
> Os is redhat enterprise, kernel 2.6.18-164.2.1.e15
> NUT is apparently 2.4.1
> It was installed by tar.
>  
> Monitoring a lot of apc UPS units?mostly Smart-UPS of various flavors, also
a Silcon DP380E.
>  
> Normally works just fine?  ?upslog? writes status log every 30 seconds with
various parameters..
>  
> Every so often, one of the UPS units has a log entry of:
>  
> 20150812+035542+NA+NA+NA+[NA]+NA+NA+NA
>  
> When it normally looks like:
>  
> 20150813+114309+100.00+115.00+39.00+[OL]+25.00+60.00+1020.00
>  
> What does it mean when it  puts NA in the log file?
Every log interval, each variable is fetched from the server, and if there is an
error retrieving that value at that time, "NA" is logged:

https://github.com/networkupstools/nut/blob/master/clients/upslog.c#L203

Since they are all "NA" at the same time, it is likely that there is a
communication problem, either between upslog and upsd, or between upsd and the
driver. In either case, there is probably a syslog message describing the
problem in more detail.

-- 
Charles Lepple
clepple at gmail

I see this in syslog:
Aug 12 03:57:22 orion upsd[18274]: Data for UPS [a102-apc-10] is stale - check
driver

(one for each UPS).

Then I see a bunch of messages like this:

Aug 12 03:58:02 orion upsd[18274]: write() failed for ::1: Broken pipe
Aug 12 03:58:02 orion snmpd[2872]: Connection from UDP: [127.0.0.1]:50940

And then it returns to normal like this:

Aug 12 03:58:04 orion upsd[18274]: UPS [a102-apc-10] data is no longer stale

Where else can I look to find out what really happened?

-Bob

-----Original Message-----
From: Charles Lepple [mailto:clepple at gmail.com] 
Sent: Thursday, August 13, 2015 9:52 PM
To: Bob Brown
Cc: nut-upsuser at lists.alioth.debian.org
Subject: Re: [Nut-upsuser] occassional problem wtih upslog and apc ups units via
snmp ... [NA] status

On Aug 13, 2015, at 12:45 PM, Bob Brown <bbrown at harpercollege.edu>
wrote:
> 
> Os is redhat enterprise, kernel 2.6.18-164.2.1.e15 NUT is apparently 
> 2.4.1 It was installed by tar.
>  
> Monitoring a lot of apc UPS units?mostly Smart-UPS of various flavors, also
a Silcon DP380E.
>  
> Normally works just fine?  ?upslog? writes status log every 30 seconds with
various parameters..
>  
> Every so often, one of the UPS units has a log entry of:
>  
> 20150812+035542+NA+NA+NA+[NA]+NA+NA+NA
>  
> When it normally looks like:
>  
> 20150813+114309+100.00+115.00+39.00+[OL]+25.00+60.00+1020.00
>  
> What does it mean when it  puts NA in the log file?
Every log interval, each variable is fetched from the server, and if there is an
error retrieving that value at that time, "NA" is logged:

https://github.com/networkupstools/nut/blob/master/clients/upslog.c#L203

Since they are all "NA" at the same time, it is likely that there is a
communication problem, either between upslog and upsd, or between upsd and the
driver. In either case, there is probably a syslog message describing the
problem in more detail.

--
Charles Lepple
clepple at gmail