Allow customization of the shutdown command UPS/NUT uses to take down the system
In my case (and other's from what I have seen) it would nice to customize via the GUI the command that the NUT tools use to shutdown the system. I have a script that nicely shuts down all of the embedded VM's relying on my FreeNAS NFS share, then it shuts down FreeNAS that's running as a VM.
I submitted a pull request #183
It was merged into master https://github.com/freenas/freenas/commit/8c9cf137a8e094d88c7f4b020662f9ec1a3be552
It would be super awesome if it could make it into the next release. :-)
#11 Updated by Jan Stevenson almost 3 years ago
Update on this:
- have set up a UPS and connected it to a FreeNAS
- have been able to successfully start up the UPS service on the FN using the usbhid-ups driver
- presently getting the nut tools installed and working on a fbsd client in order to test out the UPS interaction with the FreeNAS
- also reviewed the diff changes and verified that the new field is present in the UI->Services->UPS and that the schema migration code includes the new field as well
- next up is to figure out how to use the NUT tools and then test the interaction between calling a user defined shutdown command and the UPS device
#12 Updated by Jan Stevenson almost 3 years ago
After getting all the client side NUT tools to work, I verified that sending a fsd request to the upsmon process does call out to the script defined in the UI under Services->UPS->Shutdown Command.
The script I used:
#!/bin/sh echo "got shutdown request from upsmon" | wall
and with a 'upsmon -c fsd' call I saw the wall show up everywhere.
This action got logged to ups.log as:
20160923 144005 100 120.9 0.0 [FSD OL] NA NA
Monitoring then shows the UPS status to be:
root@jsteve-vm-fbsd:~ # upsc firstname.lastname@example.org:3493|grep ups.status ups.status: FSD OL
So my conclusion is that the SHUTDOWN command that is specified in UI does indeed get plumbed through to the UPS monitor running on the FreeNAS (upsmon). What is unclear is that after the side script/command gets called and completes then the next action should be to do continue on with the rest of shutdown, i.e to do the basic '/bin/shutdown -p now'. And that is not happening.
#13 Updated by Zach Brown almost 3 years ago
Yah, that was kind of the point.
If you want it to shutdown the system you should include the shutdown command in the script.
In my case I run a script to shutdown all freenas dependant VMS and then use the hypervisor shutdown command to shutdown freenas vs actually shutting it down with a command.
#14 Updated by Jan Stevenson almost 3 years ago
Thanks Zach. It was unclear to me if the shutdown would then get called automatically in succession by upsmon. For instance given this in upsmon.conf, for example:
NOTIFYFLAG SHUTDOWN SYSLOG+EXEC
It seemed that a different monitoring event sent via upssched would trigger this later.
I can see where adding the actual call to 'shutdown' of the FreeNAS box to script defined by SHUTDOWNCMD in upsmon.conf file could get the job done, but it seemed like it would be automatic later based on a different event?
#15 Updated by Zach Brown almost 3 years ago
I'm pretty sure the command is intended to be the one to shutdown the box. It gives the user the flexibility to do something first or the shutdown command may not be consistent from one box/distro to another. It works perfectly for me as I have set the shutdown to commence when there is about 10 minutes of runtime left in my ups. My script issues the shutdown command to all the VMS that are dependant on freenas and when they are all down it issues the shutdown command to freenas. I have freenas running on VMware serving NFS back to VMware to store virtual disks. Everything is shut down in the right order so I don't trash VMS sitting on freenas by shutting it down too soon. Once this is in, I'll contribute the script. It actually works with freenas' built in VMware support.