Search Results

Search found 3 results on 1 pages for 'mgjk'.

Page 1/1 | 1 

• APC UPS replace battery light and apcupsd reporting "replace battery"

  - by mgjk

  We have an APC Smart UPS 1500. The "Replace Battery" light is on, and apcupsd reports: Emergency! Batteries have failed on UPS xxxx. Change them NOW However, from this article, http://sturgeon.apcc.com/kbasewb2.nsf/for+external/f39c4312fcaf7b948525679a005ebb78?OpenDocument it seems that it's not so clear that the UPS battery needs to be replaced. Stranger, according to the information on the UPS, an 11 minute runtime at 42.9% load running at 27.7V isn't so bad. Any thoughts about what to try next? We're a non-profit, money is an object. It would be a shame to replace a battery with a year or so left in it. # apcaccess status APC : 001,041,1017 DATE : Thu Mar 29 13:01:41 EDT 2012 HOSTNAME : oreilly2 VERSION : 3.14.6 (16 May 2009) debian UPSNAME : xxxx CABLE : Custom Cable Smart MODEL : Smart-UPS 1500 UPSMODE : Stand Alone STARTTIME: Thu Mar 29 12:57:30 EDT 2012 STATUS : ONLINE LINEV : 112.3 Volts LOADPCT : 42.9 Percent Load Capacity BCHARGE : 100.0 Percent TIMELEFT : 11.0 Minutes MBATTCHG : 5 Percent MINTIMEL : 3 Minutes MAXTIME : 0 Seconds OUTPUTV : 112.3 Volts SENSE : High DWAKE : -01 Seconds DSHUTD : 090 Seconds LOTRANS : 106.0 Volts HITRANS : 127.0 Volts RETPCT : 000.0 Percent ITEMP : 23.8 C Internal ALARMDEL : Always BATTV : 27.7 Volts LINEFREQ : 60.0 Hz LASTXFER : No transfers since turnon NUMXFERS : 0 TONBATT : 0 seconds CUMONBATT: 0 seconds XOFFBATT : N/A SELFTEST : NO STATFLAG : 0x07000008 Status Flag SERIALNO : AS0603298896 BATTDATE : 2006-01-14 NOMOUTV : 120 Volts NOMBATTV : 24.0 Volts FIRMWARE : 601.3.D USB FW:1.5 APCMODEL : Smart-UPS 1500 END APC : Thu Mar 29 13:02:12 EDT 2012 Error when running upstest You are using a SMART cable type, so I'm entering SMART test mode mode.type = USB_UPS Setting up the port ... Hello, this is the apcupsd Cable Test program. This part of apctest is for testing Smart UPSes. Please select the function you want to perform. 1) Query the UPS for all known values 2) Perform a Battery Runtime Calibration 3) Abort Battery Calibration 4) Monitor Battery Calibration progress 5) Program EEPROM 6) Enter TTY mode communicating with UPS 7) Quit Select function number: 2 First ensure that we have a good link and that the UPS is functionning normally. Simulating UPSlinkCheck ... YWrote: Y Got: getline failed. Apparently the link is not up. Giving up.

  Read the article

• mod_fcgi in virtualmin: graceful kill fail, sending SIGKILL?

  - by mgjk

  Yesterday around 1am, our server ground to a crawl. This doesn't happen often, but I'm trying to get to the bottom of it. There is no unusual traffic volume, no unusual processes running, just all of the sudden the server started killing fcgid processes. [Thu Aug 02 01:17:32 2012] [warn] mod_fcgid: process 26460 graceful kill fail, sending SIGKILL ... for as many fcgid processes as we have... CPU idle fell to 0% and I/O seemed to take up most of the load. The issue lasted about 5 minutes. I suspect there was some swap activity, although I'm not sure if it was due to killed processes being swapped in to die, or if it was because some process ramped up memory usage faster than my process watching scripts can see them. The oom-killer wasn't triggered (at least it's not logged), so I think this was Apache for some reason restarting the processes. This is not regular, and nothing obvious appears in cron. Is there a normal Apache process which might cause this? We run dozens of different sites, and it was late at night, so volume was very, very low. (maybe 200 requests in a 10 minute period).

  Read the article

• Linux Software Raid runs checkarray on the First Sunday of the Month? Why?

  - by mgjk

  It looks like Debian has a default to run checkarray on the first Sunday of the month. This causes massive performance problems and heavy disk usage for 12 hours on my 2TB mirror. Doing this "just in case" is bizzare to me. Discovering data out of sync between the two disks without quorum would be a failure anyway. This massive checking could only tell me that I have an unrecoverable drive failure and corrupt data. Which is nice, but not all that helpful. Is it necessary? Given I have no disk errors and no reason to believe my disks have failed, why is this check necessary? Should I take it out of my cron? /etc/cron.d# tail -1 /etc/cron.d/mdadm 57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet Thanks for any insight,

  Read the article

1