On 12/03/2016 08:03 AM, Charles Lepple wrote:> On Dec 2, 2016, at 10:23 PM, Jack McGee <jack at greendesk.net> wrote: >> This is new install on Ubuntu 16.04, using packages from Synaptic, >> Network UPS Tools upsd 2.7.2 >> >> I am getting these messages in the terminal: >> Broadcast message from nut at amethi (somewhere) (Fri Dec 2 12:33:03 2016): >> >> UPS CyberUPS1 at localhost is unavailable >> >> I am still unclear on where to set when nut shutdowns system. > The basic configuration is that upsmon will shut down the system (running SHUTDOWNCMD in /etc/nut/upsmon.conf) when the UPS signals that its battery is low. > > Your UPS probably indicates this currently: > > $ upsc tl ups.status 2>/dev/null > OL > > The last line will change to "OB" when the power fails, and "OB LB" when the UPS has passed one of its low-power thresholds. > > It looks like this UPS supports both a battery level threshold, and a time-remaining threshold: > > http://networkupstools.org/ddl/Cyber_Power_Systems/CP1500PFCLCD.html > > * battery.charge.low > * battery.runtime.low > > You can adjust these with the "upsrw" command, but I don't think we have verified whether the settings are stored in non-volatile memory on this particular UPS. > >> I had problem initially starting: >> >> mythuser at amethi:/etc/nut$ sudo upsdrvctl start >> Network UPS Tools - UPS driver controller 2.7.2 >> Network UPS Tools - Generic HID driver 0.38 (2.7.2) >> USB communication driver 0.32 >> Can't claim USB device [0764:0501]: could not detach kernel driver from interface 0: Operation not permitted >> Driver failed to start (exit status=1) >> >> But that appeared to be resolved by unplugging USB cable and replugging it. >> > This bug still applies: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1540008 > > I should add a fix for that to my PPA build. > > Speaking of which, there have been some long-term stability bugs related to the USB controllers on newer motherboards with the particular USB access method that NUT uses. Full history is here, but towards the end is a success story with a similar UPS (1000PFCLCD): https://github.com/networkupstools/nut/issues/300#issuecomment-263090233 > > The PPA switches NUT from libusb-0.1 to 1.0. > > https://launchpad.net/%7Eclepple/+archive/ubuntu/nutthanks. I added the repository, updated: Preparing to unpack .../libupsclient4_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_amd64.deb ... Unpacking libupsclient4:amd64 (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over (2.7.2-4ubuntu1) ... Preparing to unpack .../nut-client_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_amd64.deb ... Unpacking nut-client (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over (2.7.2-4ubuntu1) ... Preparing to unpack .../nut-server_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_amd64.deb ... Unpacking nut-server (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over (2.7.2-4ubuntu1) ... Preparing to unpack .../nut_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_all.deb ... Unpacking nut (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over (2.7.2-4ubuntu1) ... Preparing to unpack .../nut-cgi_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_amd64.deb ... Unpacking nut-cgi (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over (2.7.2-4ubuntu1) ... Preparing to unpack .../nut-doc_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_all.deb ... Unpacking nut-doc (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over (2.7.2-4ubuntu1) ... Processing triggers for libc-bin (2.23-0ubuntu4) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for systemd (229-4ubuntu12) ... Processing triggers for ureadahead (0.100.0-19) ... Processing triggers for doc-base (0.10.7) ... Processing 4 changed doc-base files... Registering documents with scrollkeeper... Setting up libupsclient4:amd64 (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) ... Setting up nut-client (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) ... But doesn't this still indicate an error: mythuser at amethi:/etc/nut$ upscmd -l CyberPower1 Error: Connection failure: Connection refused
On 12/03/2016 08:44 AM, Jack McGee wrote:> On 12/03/2016 08:03 AM, Charles Lepple wrote: >> On Dec 2, 2016, at 10:23 PM, Jack McGee <jack at greendesk.net> wrote: >>> This is new install on Ubuntu 16.04, using packages from Synaptic, >>> Network UPS Tools upsd 2.7.2 >>> >>> I am getting these messages in the terminal: >>> Broadcast message from nut at amethi (somewhere) (Fri Dec 2 12:33:03 >>> 2016): >>> UPS CyberUPS1 at localhost is unavailable >>> >>> I am still unclear on where to set when nut shutdowns system. >> The basic configuration is that upsmon will shut down the system >> (running SHUTDOWNCMD in /etc/nut/upsmon.conf) when the UPS signals >> that its battery is low. >> >> Your UPS probably indicates this currently: >> >> $ upsc tl ups.status 2>/dev/null >> OL >> >> The last line will change to "OB" when the power fails, and "OB LB" >> when the UPS has passed one of its low-power thresholds. >> >> It looks like this UPS supports both a battery level threshold, and a >> time-remaining threshold: >> >> http://networkupstools.org/ddl/Cyber_Power_Systems/CP1500PFCLCD.html >> >> * battery.charge.low >> * battery.runtime.low >> >> You can adjust these with the "upsrw" command, but I don't think we >> have verified whether the settings are stored in non-volatile memory >> on this particular UPS. >> >>> I had problem initially starting: >>> >>> mythuser at amethi:/etc/nut$ sudo upsdrvctl start >>> Network UPS Tools - UPS driver controller 2.7.2 >>> Network UPS Tools - Generic HID driver 0.38 (2.7.2) >>> USB communication driver 0.32 >>> Can't claim USB device [0764:0501]: could not detach kernel driver >>> from interface 0: Operation not permitted >>> Driver failed to start (exit status=1) >>> >>> But that appeared to be resolved by unplugging USB cable and >>> replugging it. >>> >> This bug still applies: >> https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1540008 >> >> I should add a fix for that to my PPA build. >> >> Speaking of which, there have been some long-term stability bugs >> related to the USB controllers on newer motherboards with the >> particular USB access method that NUT uses. Full history is here, but >> towards the end is a success story with a similar UPS (1000PFCLCD): >> https://github.com/networkupstools/nut/issues/300#issuecomment-263090233 >> >> The PPA switches NUT from libusb-0.1 to 1.0. >> >> https://launchpad.net/%7Eclepple/+archive/ubuntu/nut > > > thanks. > > I added the repository, updated: > > Preparing to unpack > .../libupsclient4_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_amd64.deb ... > Unpacking libupsclient4:amd64 (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) > over (2.7.2-4ubuntu1) ... > Preparing to unpack > .../nut-client_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_amd64.deb ... > Unpacking nut-client (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over > (2.7.2-4ubuntu1) ... > Preparing to unpack > .../nut-server_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_amd64.deb ... > Unpacking nut-server (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over > (2.7.2-4ubuntu1) ... > Preparing to unpack > .../nut_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_all.deb ... > Unpacking nut (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over > (2.7.2-4ubuntu1) ... > Preparing to unpack > .../nut-cgi_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_amd64.deb ... > Unpacking nut-cgi (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over > (2.7.2-4ubuntu1) ... > Preparing to unpack > .../nut-doc_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_all.deb ... > Unpacking nut-doc (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) over > (2.7.2-4ubuntu1) ... > Processing triggers for libc-bin (2.23-0ubuntu4) ... > Processing triggers for man-db (2.7.5-1) ... > Processing triggers for systemd (229-4ubuntu12) ... > Processing triggers for ureadahead (0.100.0-19) ... > Processing triggers for doc-base (0.10.7) ... > Processing 4 changed doc-base files... > Registering documents with scrollkeeper... > Setting up libupsclient4:amd64 > (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) ... > Setting up nut-client (2.7.4-0ubuntu6~xenial~libusb1~gb0e1758) ... > > But doesn't this still indicate an error: > > mythuser at amethi:/etc/nut$ upscmd -l CyberPower1 > Error: Connection failure: Connection refusedmaybe some snippets from the config files would be useful: ups.conf: maxretry = 3 [CyberUPS1] driver = usbhid-ups port = auto vendorid=0764 upsmon.conf MONITOR CyberUPS1 at localhost 1 upsmon 5225 master POWERDOWNFLAG /etc/killpower SHUTDOWNCMD "/sbin/shutdown -h now" nut.conf MODE=netserver lsupsd.users [upsmon] password = 5225 allowfrom = localhost upsmon master upsd.conf LISTEN 127.0.0.1 3493 LISTEN ::1 3493
> On Dec 3, 2016, at 9:44 AM, Jack McGee <jack at greendesk.net> wrote: > > But doesn't this still indicate an error: > > mythuser at amethi:/etc/nut$ upscmd -l CyberPower1 > Error: Connection failure: Connection refusedCorrect - "upsc", "upscmd" and "upsrw" need to connect to "upsd", and "upsd" talks to the driver. Looks like you got the driver working before, so that configuration should still be good, but the upgrade process might have stopped it. Debian/Ubuntu both use a flag in /etc/nut/nut.conf to determine which processes to start. You will probably want to set it to either "MODE=standalone" or "MODE=netserver", then run "sudo service nut-server restart" and "sudo service nut-client restart".
On 12/03/2016 09:36 AM, Charles Lepple wrote:>> On Dec 3, 2016, at 9:44 AM, Jack McGee <jack at greendesk.net> wrote: >> >> But doesn't this still indicate an error: >> >> mythuser at amethi:/etc/nut$ upscmd -l CyberPower1 >> Error: Connection failure: Connection refused > Correct - "upsc", "upscmd" and "upsrw" need to connect to "upsd", and "upsd" talks to the driver. Looks like you got the driver working before, so that configuration should still be good, but the upgrade process might have stopped it. > > Debian/Ubuntu both use a flag in /etc/nut/nut.conf to determine which processes to start. You will probably want to set it to either "MODE=standalone" or "MODE=netserver", then run "sudo service nut-server restart" and "sudo service nut-client restart". >I did restart those services, no change.