Kevin, As Matthijs noted, pfSense uses a circular log file. The default size is ~500KB, which can be a bit small. You can increase the log file size by changing the “Log file size” parameter on the Log management page. Look for the wrench symbol on the system log page (Status / System Logs / System / General). Note that you have to clear the log after changing its size. FWIW, I have mine set to 10MB. If you want complete information on UPS discovery, the best time to capture complete information about the UPS would be after a reboot. If you are not able to reboot, then restarting the UPS service (Status / Services) will get suffice to get all the messages originating from NUT itself. It will not include the kernel discovery messages, but I don’t see a need for that here. Denny> On Aug 15, 2018, at 00:00, Kevin Mychal Ong <kevindd992002 at yahoo.com> wrote: > > Denny, > > The first three commands had outputs but the "clog /var/log/system.log | grep -i ups” didn't output any. Did I do anything wrong? This is the output without the grep: > > can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:14:59 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:15:00 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:15:26 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:15:27 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:15:53 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:15:54 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:16:20 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:16:21 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:16:47 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:16:48 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:17:14 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:17:15 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > Aug 14 18:17:41 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > > Thank you. > > Regards, > > Kevin Mychal M. Ong > Infrastructure Engineer, Microsoft Technology Services - Messaging > Global Infrastructure Operations > > Ingram Micro Inc. > 4F Three World Square, 22 Upper McKinley Hill, Fort Bonifacio > Taguig City, Philippines 1634 > > Direct +1-716-633-3600 ext. 33996 > Mobile +63-917-511-0251 > > : kevin.ong at ingrammicro.com
I'm very sorry for the delay here, I've been very swamped with work. Here's the relevant information you guys need: "upsc APC_BR1500GI" output: https://pastebin.com/rH3W0dbz "upsrw APC_BR1500GI" output: https://pastebin.com/tEWv8a3d "upscmd -l APC_BR1500GI" output: https://pastebin.com/MraRQnEk "clog /var/log/system.log | grep -i ups" output: https://pastebin.com/QxXLqEcH Let me know if you need anything else. Thank you. Regards, Kevin Mychal M. Ong Sr Infrastructure Engineer, Microsoft Technology Services - Messaging Global Infrastructure Operations Ingram Micro Inc. 4F Three World Square, 22 Upper McKinley Hill, Fort Bonifacio Taguig City, Philippines 1634 Direct +1-716-633-3600 ext. 33996 Mobile +63-917-511-0251 : kevin.ong at ingrammicro.com -----Original Message----- From: Denny Page <denny at cococafe.com> Sent: Wednesday, August 15, 2018 11:54 PM To: Kevin Mychal Ong <kevindd992002 at yahoo.com> Cc: Charles Lepple <clepple at gmail.com>; nut-upsuser at alioth-lists.debian.net Subject: Re: [Nut-upsuser] Wrong battery.date variable value Kevin, As Matthijs noted, pfSense uses a circular log file. The default size is ~500KB, which can be a bit small. You can increase the log file size by changing the “Log file size” parameter on the Log management page. Look for the wrench symbol on the system log page (Status / System Logs / System / General). Note that you have to clear the log after changing its size. FWIW, I have mine set to 10MB. If you want complete information on UPS discovery, the best time to capture complete information about the UPS would be after a reboot. If you are not able to reboot, then restarting the UPS service (Status / Services) will get suffice to get all the messages originating from NUT itself. It will not include the kernel discovery messages, but I don’t see a need for that here. Denny> On Aug 15, 2018, at 00:00, Kevin Mychal Ong <kevindd992002 at yahoo.com> wrote: > > Denny, > > The first three commands had outputs but the "clog /var/log/system.log | grep -i ups” didn't output any. Did I do anything wrong? This is the output without the grep: > > can't allocate llinfo for <Public IP> on igb0 Aug 14 18:14:59 pfSense > kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 Aug > 14 18:15:00 pfSense kernel: arpresolve: can't allocate llinfo for > <Public IP> on igb0 Aug 14 18:15:26 pfSense kernel: arpresolve: can't > allocate llinfo for <Public IP> on igb0 Aug 14 18:15:27 pfSense > kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 Aug > 14 18:15:53 pfSense kernel: arpresolve: can't allocate llinfo for > <Public IP> on igb0 Aug 14 18:15:54 pfSense kernel: arpresolve: can't > allocate llinfo for <Public IP> on igb0 Aug 14 18:16:20 pfSense > kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 Aug > 14 18:16:21 pfSense kernel: arpresolve: can't allocate llinfo for > <Public IP> on igb0 Aug 14 18:16:47 pfSense kernel: arpresolve: can't > allocate llinfo for <Public IP> on igb0 Aug 14 18:16:48 pfSense > kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 Aug > 14 18:17:14 pfSense kernel: arpresolve: can't allocate llinfo for > <Public IP> on igb0 Aug 14 18:17:15 pfSense kernel: arpresolve: can't > allocate llinfo for <Public IP> on igb0 Aug 14 18:17:41 pfSense > kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 > > Thank you. > > Regards, > > Kevin Mychal M. Ong > Infrastructure Engineer, Microsoft Technology Services - Messaging > Global Infrastructure Operations > > Ingram Micro Inc. > 4F Three World Square, 22 Upper McKinley Hill, Fort Bonifacio Taguig > City, Philippines 1634 > > Direct +1-716-633-3600 ext. 33996 > Mobile +63-917-511-0251 > > : kevin.ong at ingrammicro.comThis email may contain material that is confidential, and proprietary to Ingram Micro, for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. [Ingram_2818e5de]
Charles Lepple
2018-Aug-30 13:37 UTC
[Nut-upsuser] Wrong battery.date variable value [APC, usbhid-ups]
On Aug 30, 2018, at 6:54 AM, Ong, Kevin wrote:> > I'm very sorry for the delay here, I've been very swamped with work. Here's the relevant information you guys need: > > "upsc APC_BR1500GI" output: https://pastebin.com/rH3W0dbz > "upsrw APC_BR1500GI" output: https://pastebin.com/tEWv8a3d > "upscmd -l APC_BR1500GI" output: https://pastebin.com/MraRQnEk > "clog /var/log/system.log | grep -i ups" output: https://pastebin.com/QxXLqEcHHi Kevin, The key points here are the usbhid-ups driver (versus the serial APC driver), a serial number that appears to be more recent than some of the correct values in the DDL, and that this looks like the battery.mfr.date matches the value from apcupsd. Is the ups.mfr.date value incorrect as well, or has the battery been changed at least once in 2016? battery.date: 2001/09/25 battery.mfr.date: 2016/05/11 ups.mfr.date: 2012/01/30 The next test involves stopping NUT, and briefly running the driver in debug mode. The commands will be something like this (run in a shell as root): upsdrvctl stop /usr/local/libexec/nut/usbhid-ups -a APC_BR1500GI -DDDDD 2>&1 | tee /tmp/APC_BR1500GI.debug.txt # let it run for ~20 seconds, then stop with Control-C upsdrvctl start and then please post the contents of /tmp/APC_BR1500GI.debug.txt (pastebin works, but if you do email it to the list, please use gzip first) If the debug log looks like it ended on its own (messages to the effect of not being able to find the device), you may need to wait longer after stopping the driver, or maybe unplug and re-plug the USB cable on the UPS. (Not usually an issue with APC devices, but you never know.)