El 15/07/15 a les 15:19, Charles Lepple ha escrit:> On Jul 15, 2015, at 8:46 AM, dmanye <dmanye at urv.cat> wrote: > >> El 15/07/15 a les 14:18, Charles Lepple ha escrit: >>> On Jul 15, 2015, at 7:17 AM, dmanye <dmanye at urv.cat> wrote: >>> >>>> i have a computer (with debian 8 jessie installed) that i want to plug to an ups (apc smt 750i) to act in netserver mode. i've installed nut packages and configured it and all seems to work ok except that when the server shutdown itself it ups doesn't "reboot" the outlets. >>> What is the exact NUT package version >> 2.4.2-4 > 2.7.2-4? (Sorry to sound pedantic, just trying to get the right version in the list archives.) I was concerned that there was an older package sticking around, but that is of course less likely with a new install.oops, yes, 2.7.2-4.> >>> , and which driver are you using? >> usbhid-ups >>> Also, is this a new Debian installation, or was it upgraded from wheezy? >> new install >>> (If I understand correctly - I haven't upgraded yet - this determines which init system is used to control the shutdown.) >> yes, debian 8 by default installs systemd but i've switched back to sysvinit (2.88dsf-59) on both computers. in fact, libsystemd0 remains installed because essential packages depend on it. > libsystemd0 shouldn't matter - I just wanted to make sure I was looking at the correct init scripts. Here's nut-server.init corresponding to 2.7.2-4: > > http://anonscm.debian.org/cgit/collab-maint/nut.git/tree/debian/nut-server.init?id=564becd819124049542e5085a7159dd62e00ef97#n151 > > It does "/sbin/upsdrvctl shutdown", which runs "/lib/nut/usbhid-ups -a <name-of-ups> -k" to kill power: > > http://anonscm.debian.org/cgit/collab-maint/nut.git/tree/drivers/upsdrvctl.c?id=564becd819124049542e5085a7159dd62e00ef97#n337 > > In the output of "upsc" for your UPS, is "ups.start.auto" turned on?ups.start.auto does not appear neither on the computer that makes the ups reboot nor in the other.> Do the values for "ups.delay.shutdown" and "ups.delay.start" (times in seconds) look reasonable?ups.delay.shutdown is set to 20 on both computers, and ups.delay.start is missing in both outputs. i'd like to note that i have not used upsrw at all to modify any variable.> > What you can do is run "/lib/nut/usbhid-ups -a <name-of-ups> -k -DDD" (as root) with the computer powered from another UPS or outlet. That will show any debug messages as the driver tries to shut down the UPS. (The driver tries "shutdown.return" before "shutdown.stayoff".) You may want to add "2>&1 | tee /tmp/ups-shutdown.log" to the command line, then gzip and attach that log to your reply to keep the message size small. >surprisingly, now both computers made the ups reboot !?!?!?!? so i've tried once more and confirmed that while forcing the reboot works, the computer itself does not reboot the ups when the battery is too low. i attach you four files: upsc-no-reboot.gz upsc output from the computer that makes NOT the ups reboot upsc-reboot.gz upsc output from the computer that makes the ups reboot ups-shutdown.log-no-reboot.gz usbhid-ups -k output from the computer that makes NOT the ups reboot ups-shutdown.log-reboot.gz usbhid-ups -k output from the computer that makes the ups reboot charles, many thanks for your time. david. -------------- next part -------------- A non-text attachment was scrubbed... Name: ups-shutdown.log-reboot.gz Type: application/gzip Size: 3694 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150716/0b6fb0e0/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: ups-shutdown.log-no-reboot.gz Type: application/gzip Size: 3615 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150716/0b6fb0e0/attachment-0001.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: upsc-reboot.gz Type: application/gzip Size: 406 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150716/0b6fb0e0/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: upsc-no-reboot.gz Type: application/gzip Size: 410 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150716/0b6fb0e0/attachment-0003.bin>
On Jul 16, 2015, at 5:09 AM, dmanye <dmanye at urv.cat> wrote:> surprisingly, now both computers made the ups reboot !?!?!?!? so i've tried once more and confirmed that while forcing the reboot works, the computer itself does not reboot the ups when the battery is too low.I think you figured it out: the UPS probably has another low-battery threshold, below which it will not start back up until it charges some more. If the UPS shuts down at 10%, and the power comes back briefly, there would be a period of time where the computer is powered, but NUT hasn't started. Usually, this is shown as the "battery.charge.restart" variable, but I have a feeling that this is one of the APC Smart-UPS models that has a lot more settings available via other protocols. Here is some more background info: http://article.gmane.org/gmane.comp.monitoring.nut.devel/6749 What does 'lsusb -d 051d: -vvv' return? -- Charles Lepple clepple at gmail
El 16/07/15 a les 14:16, Charles Lepple ha escrit:> On Jul 16, 2015, at 5:09 AM, dmanye <dmanye at urv.cat> wrote: > >> surprisingly, now both computers made the ups reboot !?!?!?!? so i've tried once more and confirmed that while forcing the reboot works, the computer itself does not reboot the ups when the battery is too low. > I think you figured it out:no, i didn't figure out: it's just my poor english. for "the battery is too low" i meant when the computer "decides" to start the shutdown process.> the UPS probably has another low-battery threshold, below which it will not start back up until it charges some more. If the UPS shuts down at 10%, and the power comes back briefly, there would be a period of time where the computer is powered, but NUT hasn't started. > > Usually, this is shown as the "battery.charge.restart" variable, but I have a feeling that this is one of the APC Smart-UPS models that has a lot more settings available via other protocols. > > Here is some more background info: > > http://article.gmane.org/gmane.comp.monitoring.nut.devel/6749 > > What does 'lsusb -d 051d: -vvv' return?i attached lsusb-051d.gz at least, now i know the computer is able to force the ups to reboot. tomorrow i'll try to discover why it refuses to do so. thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: lsusb-051d.gz Type: application/gzip Size: 683 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150716/36925b8e/attachment.bin>
El 16/07/15 a les 14:16, Charles Lepple ha escrit:> On Jul 16, 2015, at 5:09 AM, dmanye <dmanye at urv.cat> wrote: > >> surprisingly, now both computers made the ups reboot !?!?!?!? so i've tried once more and confirmed that while forcing the reboot works, the computer itself does not reboot the ups when the battery is too low. > I think you figured it out: the UPS probably has another low-battery threshold, below which it will not start back up until it charges some more. If the UPS shuts down at 10%, and the power comes back briefly, there would be a period of time where the computer is powered, but NUT hasn't started. > > Usually, this is shown as the "battery.charge.restart" variable, but I have a feeling that this is one of the APC Smart-UPS models that has a lot more settings available via other protocols. > > Here is some more background info: > > http://article.gmane.org/gmane.comp.monitoring.nut.devel/6749 > > What does 'lsusb -d 051d: -vvv' return? >now i get it working although i really understand nothing. while the commands '/sbin/upsdrvctl shutdown' and 'lib/nut/usbhid-ups -a <name-of-ups> -k' make the ups to force a reboot on the computer, the command 'upsmon -c fsd' fails and the ups does not reboot the output outlets. i also tried to, once upsmon is running, set the powerdown flag with its magic string and then issue the 'upsmon -c fsd'. fail. one of the last messages of the computer before powering off is something like the power down flag is not set. then i reinstalled the computer to get a fresh install (it's easy because i'm using netinstall+preseed). test again and failed again. so i reinstalled again... but instead of using four separate partitions for /, /usr, /var and /tmp, put all the stuff under an unique / partition and... it works! why exactly? no idea, because if i'm not wrong, nut sensitive stuff is under /lib, /sbin, /etc... works? yes BUT... i put in /etc/default/halt HALT=halt (by default it contains HALT=poweroff) so that the last messages remain on screen to look for possible error messages and it stopped working. if i put HALT=poweroff again, the ups is rebooted. so, does anybody know why having separate partitions conditions nut behaviour? and why /etc/default/halt has also effect on why nut does with the ups? thanks.