Nut upsuser - Jul 2016 - FSD sequence not working on Ubuntu 16.04 LTS

Hi Charles,

On Wednesday, July 13, 2016 11:40:09 PM Charles Lepple
wrote:
> On Jul 12, 2016, at 5:27 PM, Ivan Adzhubey <iadzhubey at
rics.bwh.harvard.edu>
> wrote:
> > I have recently installed NUT 2.7.3.1 on a freshly installed Ubuntu
16.04
> > LTS (64-bit) system, connected via USB cable to APC Smart-UPS 1500
(SMT
> > model). I am trying to make this configuration work for automatic
> > shutdown/restart but it seems that it completely ignores
/etc/killpower
> > presence. I know the APC SMT models are problematic but it looks like
I
> > could not even make the simplest test work, so it is likely
initscripts
> > issue and not the driver/UPS.
>
> The only Ubuntu 16.04 system I have worked with is a laptop (so no UPS),
and
> I have to say that it doesn't feel as much like an LTS release as
14.04.
> Can you reproduce the shutdown issue with upstart instead of systemd?
> (alternate GRUB menu option, IIRC)
Ubuntu Server 16.04 does not have the upstart option on boot menu. In fact, I 
do not believe any Ubuntu Server used it, ever.

Anyway, now that even Debian announced dropping support for sysvinit 
compatibility we will have to learn how to live with systemd, like it or not.
> I'm not sure if the PPA is the best solution at the moment, or whether
the
> Ubuntu systemd files have been merged in. There is the following comment in
> the buildlog:
> 
> # Install systemd files only on systems where it's supported
> # disabled in Ubuntu until the unit gets fixed to check nut.conf
> 
> I would recommend filing a bug with Ubuntu. It would help them track things
> down if you can identify the logs which should be running the systemd
> equivalent of "upsdrvctl shutdown" or "<driver>
-k".
The bug was caused by the NUT package lacking systemd-specific halt/poweroff 
script. Ubuntu 16.04 have systemd SysV init compatibility layer installed by 
default and it works fine for most of the services managed by legacy 
initscripts. However, the one important exception is halt/poweroff/reboot 
mechanism, for which there is no compatibility support. Systemd does not run 
/etc/init.d/halt script at all, while NUT relies on this script to run 
/etc/init.d/ups-monitor command which, in turn, checks for the presence of 
killpower flag and run "nut-server poweroff" command to cut the UPS
load power,
if that flag is found.

I followed the instructions on this blog:

https://www.kepstin.ca/blog/networkupstoolsnutandsystemd/

by creating the file /lib/systemd/system-shutdown/nutshutdown with the 
following commands in it:

#!/bin/sh
/sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown

After that, NUT server would correctly process power loss events (both real 
and simulated) by cutting UPS power after a system shutdown and restarting it 
after a short delay when/if the power is back.

I am going to file a bug report at Launchpad for this issue.

Thanks,
Ivan

On Jul 15, 2016, at 6:05 PM, Ivan Adzhubey <iadzhubey at
rics.bwh.harvard.edu> wrote:
> 
> Anyway, now that even Debian announced dropping support for sysvinit 
> compatibility we will have to learn how to live with systemd, like it or
not.
[grumble; systemd rant deleted]
> After that, NUT server would correctly process power loss events (both real
> and simulated) by cutting UPS power after a system shutdown and restarting
it
> after a short delay when/if the power is back.
> 
> I am going to file a bug report at Launchpad for this issue.
Thank you for tracking this down. (I'm still wrestling with vagrant and
VirtualBox, trying to set up a 16.04 test environment...)

Please let us know the Launchpad URL for the issue once it is filed.

-- 
Charles Lepple
clepple at gmail

On Friday, July 15, 2016 11:25:30 PM EDT Charles Lepple
wrote:
> On Jul 15, 2016, at 6:05 PM, Ivan Adzhubey <iadzhubey at
rics.bwh.harvard.edu>
> wrote:
> > After that, NUT server would correctly process power loss events (both
> > real and simulated) by cutting UPS power after a system shutdown and
> > restarting it after a short delay when/if the power is back.
> > 
> > I am going to file a bug report at Launchpad for this issue.
> 
> Thank you for tracking this down. (I'm still wrestling with vagrant and
> VirtualBox, trying to set up a 16.04 test environment...)
> 
> Please let us know the Launchpad URL for the issue once it is filed.
https://bugs.launchpad.net/bugs/1603609

--Ivan