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.
On 7/17/2015 6:42 AM, dmanye wrote:> 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...My guess is it has to do with the time in the shutdown process where the file systems are unmounted. I had a similar problem when I set up Nut a few years ago.> > 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. > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser >
On Jul 17, 2015, at 9:42 AM, dmanye <dmanye at urv.cat> wrote:> 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...Please file a bug with Debian - I thought that multiple partitions worked? However, I wonder if something got broken with having /var on a separate partition. NUT stores some files in /var/run/nut but on my wheezy setup, /var/run is a symlink to /run (on tmpfs) so there shouldn't be an issue. Does 'lsof' show any references to /var that would prevent proper shutdown? -- Charles Lepple clepple at gmail
El 18/07/15 a les 17:03, Charles Lepple ha escrit:> On Jul 17, 2015, at 9:42 AM, dmanye <dmanye at urv.cat> wrote: > >> 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... > Please file a bug with Debian - I thought that multiple partitions worked? > > However, I wonder if something got broken with having /var on a separate partition. NUT stores some files in /var/run/nut but on my wheezy setup, /var/run is a symlink to /run (on tmpfs) so there shouldn't be an issue. Does 'lsof' show any references to /var that would prevent proper shutdown? >hello, i've repeated the installation process. my partman preseed setup contains separate partitions for / /boot /usr /var /tmp with this setup, issuing the command 'upsmon -c fsd' stops the server but does not make the ups 'reboot' the output outlets. i've repeated the installation without a separate partition for /var (so /var is contained in / partition) and the result is the same. so /var seems not to be the problem. i've repeated the installation without a separate partition for /usr (so /usr is contained in / partition) and the result is that now it works: the server is stopped and the ups is 'rebooted'. i did all these tests using the default systemd, and also replacing it with sysvinit. the results were the same independently of the init system used. looking at my /etc/rc0.d, nut client and server have number 01 and filesystems (not root) are unmounted at 06, root is unmounted at 07 and finally in 08 system is halted / poweroff. these numbers depend on the services installed on the system, but the order should be the same. if /usr is in a separate partition, it is unmounted at 07 (and "disappears"). if it is within /, in 08 it is still there because root is not unmounted, it is just mounted read-only. i think the problem is that the nut stop scripts does not trigger the ups reboot *before* finishing and before the stop system pass to the next level. the process to trigger the reboot is done in parallel with the system shutdown and if /usr is gone it fails to reboot the ups. what do you think? am i wrong? thanks.