Bug 998099 - unreliable since at least 2-3 years
Summary: unreliable since at least 2-3 years
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: apcupsd
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-17 08:50 UTC by Harald Reindl
Modified: 2016-06-23 16:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-23 16:08:46 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Harald Reindl 2013-08-17 08:50:48 UTC
two different APC UPS (the second one is a 19 "rack-mount)

i remeber that for the "Back-UPS RS 1200 LCD" a few years ago the problems started with a apcupsd version-jump but i never thought that this would stay forever and since it was AFAIR shot before christmas i sadly did not make a bug-report as it began
______________________________________________________

oh yeah "TIMELEFT : 790.0 Minutes" would be nice but is not true

MODEL    : Back-UPS RS 1200 LCD 
STATUS   : ONLINE 
LINEV    : 224.0 Volts
LOADPCT  :   0.0 Percent Load Capacity
BCHARGE  : 100.0 Percent
TIMELEFT : 790.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
SENSE    : Medium
______________________________________________________

HID v1.00 Device [American Power Conversion Smart-UPS 2200 FW:UPS 06.5 / ID=18]

directly after boot the linux machine following output
from "apcaccess", and no, you can't easily remove the battery from a 19" rack-mount UPS and so i guess it was always there (this NOBATT is displayed randomly after days too)

STATUS   : ONLINE NOBATT 
BCHARGE  : 000.0 Percent
TIMELEFT :   0.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
ALARMDEL : 30 seconds
BATTV    : 00.0 Volts

a few hours later it *may* return te right values

NOW:
Aug 17 10:34:03 backup-thx1138 apcupsd[497]: Battery disconnected.
Aug 17 10:37:26 backup-thx1138 apcupsd[497]: Battery reattached.

APC      : 001,026,0640
DATE     : 2013-08-17 10:41:23 +0200  
HOSTNAME : backup-thx1138.thelounge.net
VERSION  : 3.14.10 (13 September 2011) redhat
UPSNAME  : TL-BKP
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2013-08-17 10:33:50 +0200  
MODEL    : 
STATUS   : ONLINE 
BCHARGE  : 100.0 Percent
TIMELEFT :   0.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
ALARMDEL : 30 seconds
BATTV    : 00.0 Volts
NUMXFERS : 0
TONBATT  : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
STATFLAG : 0x07000008 Status Flag
MANDATE  : 1980-00-00
SERIALNO : 
NOMBATTV :   0.0 Volts
END APC  : 2013-08-17 10:41:25 +0200

because this bullshit "TIMELEFT: 0.0 Minutes" and "BCHARGE: 100% Percent" Wednesday night this damned crap did shutdown most of my backup-infrastructure because it tends also to faulty detect powerloss and by luck most of the time it detects fast enough "power return" while it was never away

http://serverfault.com/questions/444367/apcupsd-slave-client-keeps-loosing-and-restoring-communications-with-ups-master
______________________________________________________

Comment 1 Harald Reindl 2013-08-17 09:01:02 UTC
Oh, i have also *one* example where it works perfect fine

tht's at home, the "Back-UPS RS 1200 LCD" is on the same hardware (HP Compaq 8200 Elite CMT PC) and so "apcupsd" seems to have big problems with different APC UPS 

[root@srv-rhsoft:~]$ apcaccess 
APC      : 001,038,1027
DATE     : 2013-08-17 10:58:34 +0200  
HOSTNAME : srv-rhsoft.rhsoft.net
VERSION  : 3.14.10 (13 September 2011) redhat
UPSNAME  : srv-rhsoft
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2013-08-16 13:59:20 +0200  
MODEL    : Back-UPS BR1200GI 
STATUS   : ONLINE 
LINEV    : 235.0 Volts
LOADPCT  :  10.0 Percent Load Capacity
BCHARGE  : 100.0 Percent
TIMELEFT :  50.8 Minutes
MBATTCHG : 10 Percent
MINTIMEL : 10 Minutes
MAXTIME  : 0 Seconds
SENSE    : High
LOTRANS  : 176.0 Volts
HITRANS  : 288.0 Volts
ALARMDEL : 30 seconds
BATTV    : 27.8 Volts
LASTXFER : Automatic or explicit self test
NUMXFERS : 1
XONBATT  : 2013-08-17 09:49:45 +0200  
TONBATT  : 0 seconds
CUMONBATT: 3 seconds
XOFFBATT : 2013-08-17 09:49:48 +0200  
LASTSTEST: 2013-08-17 09:49:45 +0200  
SELFTEST : NO
STATFLAG : 0x07000008 Status Flag
SERIALNO : 3B1040X42713  
BATTDATE : 2011-01-12
NOMINV   : 230 Volts
NOMBATTV :  24.0 Volts
NOMPOWER : 720 Watts
FIRMWARE : 877.L2 .I USB FW:L2                     
END APC  : 2013-08-17 10:58:41 +0200

Comment 2 Harald Reindl 2013-08-17 09:36:32 UTC
maybe this sequence from the syslog after boot is interesting

Aug 17 10:34:01 backup-thx1138 apcupsd[497]: apcupsd 3.14.10 (13 September 2011) redhat startup succeeded
Aug 17 10:34:01 backup-thx1138 apcupsd[497]: NIS server startup succeeded
Aug 17 10:34:03 backup-thx1138 apcupsd[497]: Battery disconnected.
Aug 17 10:37:26 backup-thx1138 apcupsd[497]: Battery reattached.
____________________________

it says still no time left while before reboot 
it displayed around 45 minutes which is the truth 

STATUS   : ONLINE 
BCHARGE  : 100.0 Percent
TIMELEFT :   0.0 Minutes

Comment 3 Harald Reindl 2013-08-17 23:27:42 UTC
as expected, after some hours the Smart-UPS 2200 shows correct values until it for random reasons falls back to wrong values as well as faulty "on batt" alerts leading in rare cases due the "no time left" to a shutdown



[root@backup-thx1138:~]$ apcaccess 
APC      : 001,026,0640
DATE     : 2013-08-18 01:23:57 +0200  
HOSTNAME : backup-thx1138.thelounge.net
VERSION  : 3.14.10 (13 September 2011) redhat
UPSNAME  : TL-BKP
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2013-08-17 10:33:50 +0200  
MODEL    : 
STATUS   : ONLINE 
BCHARGE  : 100.0 Percent
TIMELEFT :  44.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
ALARMDEL : 30 seconds
BATTV    : 54.8 Volts
NUMXFERS : 0
TONBATT  : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
STATFLAG : 0x07000008 Status Flag
MANDATE  : 1980-00-00
SERIALNO : 
NOMBATTV :   0.0 Volts
END APC  : 2013-08-18 01:24:14 +0200  

[root@backup-thx1138:~]$ systemctl status apcupsd.service 
apcupsd.service - APC UPS Power Control Daemon for Linux
   Loaded: loaded (/usr/lib/systemd/system/apcupsd.service; enabled)
   Active: active (running) since Sa 2013-08-17 10:33:50 CEST; 14h ago
  Process: 493 ExecStartPre=/bin/rm -f /etc/apcupsd/powerfail (code=exited, status=0/SUCCESS)
 Main PID: 497 (apcupsd)
   CGroup: name=systemd:/system/apcupsd.service
           └─497 /sbin/apcupsd -b -f /etc/apcupsd/apcupsd.conf

Comment 4 Harald Reindl 2013-08-23 10:14:41 UTC
"apcaccess" after reboot the system

STATUS   : ONLINE NOBATT 
BCHARGE  : 000.0 Percent
TIMELEFT :   0.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds

Comment 5 Fedora End Of Life 2013-12-21 14:29:33 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Fedora End Of Life 2015-05-29 09:19:43 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Fedora End Of Life 2015-11-04 11:44:22 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 Fedora Admin XMLRPC Client 2016-06-22 15:43:33 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 9 Fedora Admin XMLRPC Client 2016-06-22 19:18:26 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Jason Tibbitts 2016-06-22 20:17:09 UTC
I have just taken over this package and am looking through the tickets.

First off, the current version is 3.14.14 and upstream indicates significant USB protocol changes, new protocol support, and workarounds for at least some types of communication issues.  That version is in all supported Fedora releases currently.  It would be good to check that version before I spend too much time looking into this.

Also, as far as I can tell, this isn't an issue with the Fedora package and so it would be much better if this were at least sent upstream somewhere.  Has this already been reported there?  Reading through three years of sourceforge mailing list archives is beyond the scope of what I can do right now.

Comment 11 Harald Reindl 2016-06-22 21:02:52 UTC
Well, there did not much change in the last years - the only 100% reliable one is still the ups at home while the one in the main office still randomly pretends NOBATT and the one in our small second office pretends there is zero load while it backed multiple power outages over the tine

Comment 12 Jason Tibbitts 2016-06-22 21:28:14 UTC
Well, plenty of things have changed in the software itself, which is why I'm asking for testing with the current version.  And which is also why I asked if this had been reported upstream.

Comment 13 Harald Reindl 2016-06-22 21:34:56 UTC
As a regular updates-testing user over nearly 10 years i am running the current version from the Fedora repositories

Comment 14 Jason Tibbitts 2016-06-22 21:51:49 UTC
I don't know how you expected me to know that, but OK.  So the next step is to report it upstream if it hasn't been reported there already.  Since you seem to be refusing to answer that question, I'm just going to assume that you haven't.

I haven't seen anything like this myself so I'm not going to be able to do any real experimentation into your issue.  And I doubt this is a specific issue with the Fedora package, though you're welcome to build directly from source to double check if you like.

I can report it for you and deal with upstream, but that's going to be woefully inefficient because I'll just have to ask you for any information they request.  Is that what you'd like for me to do, or would you like to contact upstream yourself?

Comment 15 Harald Reindl 2016-06-22 21:58:01 UTC
Don't get me wrong but i can't register on every upstream bugtracker

Comment 16 Jason Tibbitts 2016-06-22 22:02:59 UTC
Of course not, which is why I offered you the option.  I'm just going to assume from your response that you would prefer that I report this for you, and I'll go ahead and do that now.

Comment 17 Jason Tibbitts 2016-06-23 03:09:36 UTC
Assuming you're willing to follow a mailing list archive, please see the thread beginning at http://article.gmane.org/gmane.comp.sysutils.apcupsd.user/10973

Note the first followup which indicates that at least one person has had similar problems, caused by bad batteries and the fact that the UPS failed to report that the batteries were bad.

Recall that the expected lifetime of an APC battery is generally about three years, so if they hadn't been changed since before you opened this ticket, they are almost certainly well beyond their expected lifetime.

Really, if the issue you report was a general issue with the software, there wouldn't be any point in actually running it as it would be completely useless.  But instead it seems to work well for a great many people.

Perhaps you should try NUT for a while and see if it reports the same issues?

Comment 18 Harald Reindl 2016-06-23 10:10:12 UTC
NUT with it's different services, manadtory needed configuration and a broken default setup don't impress me much :-(

Jun 23 12:07:06 srv-rhsoft upsdrvctl: Can't chdir to /var/run/nut: No such file or directory

Comment 19 Jason Tibbitts 2016-06-23 16:08:46 UTC
In case you're not following along, there was a suggestion that you try accessing the smart-ups 2200 via serial because the USB support on that model wasn't great.

Otherwise, the consensus seems to be that it is most likely that you simply have flaky UPSes.  There's really not much else I can do here, and I'm going to close this.  If you can reproduce this on a UPS which works fine with other software then feel free to repoen, or bring it up with upstream directly.


Note You need to log in before you can comment on or make changes to this bug.