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 ______________________________________________________
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
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
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
"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
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.
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.
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
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
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.
As a regular updates-testing user over nearly 10 years i am running the current version from the Fedora repositories
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?
Don't get me wrong but i can't register on every upstream bugtracker
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.
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?
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
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.