shutdown equivalent of 'go' script (running script at shutdown that is persisted across reboots)


Recommended Posts

Looking to run a script that shuts down my disk shelves on unraid shutdown. I've configured poweroff delays on my switched PDU, and I'm sending snmp commands to the PDU to make it work.

Problem is, I'm using /etc/rc.d/rc.0 as the script location, and this is in the RAMdisk, so it doesn't persist across reboots. There used to be a powerdown script, but that's apparently been deprecated, and rc.0 just calls /sbin/poweroff, which is a binary.

Basically, I'm looking for the shutdown equivalent of the go script

Link to comment
36 minutes ago, itimpi said:

Create a 'stop' script in the config folder on the flash drive.  If present this is run late in the shutdown sequence.   I have long thought that Unraid should provide as standard a dummy 'stop' file that does nothing to make it clear this is possible.

 

Ah, this could be perfect -- do you know if it runs before or after networking is unloaded, or can you point me to what script calls the stop script? The most ideal place to put this script is RIGHT before the poweroff call, just like a UPS killpower command, but just like the UPS killpower command, this won't work over SNMP because networking is already unloaded by then. Annoyingly, filesystems appear to be unmounted after stopping networking, so the only real option is to have a long poweroff delay on the outlets and send the request at the beginning of the shutdown.

Probably fair to assume it's before the rc.0 script is called at all, so I'll give it a shot!

Link to comment

Come to think of it, this will probably run on both reboot and shutdown -- if the outlet timeout is long enough, and the scripts robust enough, it shouldn't be a problem for functionality, but it could slow down reboots considerably. Any ideas as to how I might ensure it only runs on shutdown?

Link to comment
2 hours ago, drumstyx said:

Come to think of it, this will probably run on both reboot and shutdown -- if the outlet timeout is long enough, and the scripts robust enough, it shouldn't be a problem for functionality, but it could slow down reboots considerably. Any ideas as to how I might ensure it only runs on shutdown?

No idea how you would tell the difference between a reboot and a shutdown.

 

3 hours ago, drumstyx said:

Ah, this could be perfect -- do you know if it runs before or after networking is unloaded, or can you point me to what script calls the stop script?

I will see if I can determine exactly what has been done already when it runs.   Should be able to capture when it runs from the diagnostics I have built into my plugins.   Not looked at what invokes it but you might be able to find out by running a grip for ‘stop’ on the various rc files in the /etc/cron.d folder.

Link to comment

Got it -- runlevel is 0 for shutdown, 6 for reboot, 3 for normal operation

For posterity, here's my hacked-together script for it:

#!/bin/sh
currentRunLevel=$(runlevel | awk {'print $NF'})
echo "*********** THE CURRENT RUN LEVEL IS ***********"
echo $currentRunLevel

if [[ $(echo $currentRunLevel) = 0 ]]; then
    snmpset -v 1 -c private 192.168.42.20 1.3.6.1.4.1.318.1.1.12.3.3.1.1.4.1 integer 5
    snmpset -v 1 -c private 192.168.42.20 1.3.6.1.4.1.318.1.1.12.3.3.1.1.4.2 integer 5
    snmpset -v 1 -c private 192.168.42.20 1.3.6.1.4.1.318.1.1.12.3.3.1.1.4.5 integer 5
fi


The echos at the top were just for me to test that runlevel was changed before the script is executed, and indeed it seems it can be relied on.

 

To add: this script runs pretty much immediately when a shutdown is triggered (at least from GUI). BEFORE unloading anything. Technically, that means it's not an ideal spot for it, but since unraid force kills things after 90 seconds (at least, that's what I assume when it says it's allowing 90 seconds for graceful shutdown) my timers getting triggered over snmp are fine at 180 seconds.

The only downsides to the timeouts is that coming back up after power loss is a rather long process (I've got a raspberry pi that listens for UPS OFFBATTERY state and brings things back, but it needs to wait longer than the timeout to make sure the server isn't currently trying to shut down), and power is consumed from the UPS for longer than is really necessary, but only a minute or two extra. You just can't make the timings too tight, otherwise if there are any hangups during shutdown, it could kill the power too soon.

EDIT: This isn't a thread for SNMP specifically, but I thought I'd note what the heck those long strings are: OIDs for the outlets on my PDU. APC provides MIB files to use in an MIB browser, and with some digging you can figure out how to control various things. It's a pain, not to mention archaic, but it's neat once it's set up. I'm positive I'll hate myself if I ever move outlets around and forget I set this up, but for now it's a blast!

Edited by drumstyx
  • Like 2
Link to comment
  • 1 month later...
On 12/9/2021 at 11:17 AM, itimpi said:

Create a 'stop' script in the config folder on the flash drive.  If present this is run late in the shutdown sequence.   I have long thought that Unraid should provide as standard a dummy 'stop' file that does nothing to make it clear this is possible.

 

Hi! Please, could you give more information about how to do this? Is there any mechanism to run a script earlier (not late) in the shutdown sequence?

 

Thank you!

Link to comment
  • 8 months later...
On 2/2/2022 at 2:15 PM, Audio01 said:

 

Hi! Please, could you give more information about how to do this? Is there any mechanism to run a script earlier (not late) in the shutdown sequence?

 

Thank you!

The stop script is just about the earliest you could want anything to run. Shutdown is initiated with /sbin/init 0, which sets the runlevel to 0, at which point the absolute earliest hook is the first line of /etc/rc.d/rc.0 (after "#!/bin/bash", of course). The number after "rc." in the script name is the runlevel. Runlevel 0 is shutdown (aka "halt", officially) and runlevel 6 is reboot. In Unraid, rc.0 is just an alias for rc.6, and one script handles both things, as it looks to see which runlevel it was called as.

The only scripts that run before /boot/config/stop are scripts within /etc/rc.d/rc0.d/ or /etc/rc.d/rc6.d/, depending on runlevel, which at this point contains only the flash backup of the myservers plugin, if applicable.

 

All that to say, to run things EARLY in the shutdown process is easy -- /boot/config/stop. To run things LATE in the shutdown process is hard, and would involve either modifying the base unraid image on flash, or adding something in the go script to modify rc.6 to your liking on boot (either copying a complete file, which would have to be modified manually with each OS update, or some awk/sed/bash magic to modify the last if statement in rc.6)

Link to comment
48 minutes ago, drumstyx said:

To run things LATE in the shutdown process is hard

You can create the config/stop file on the flash drive which is the shutdown equivalent to the config/go file used during startup.  I have always thought that an empty version of this file (which contains nothing but a comment) should be provided as standard to make it more easily discoverable.

Link to comment
On 10/18/2022 at 11:29 AM, itimpi said:

You can create the config/stop file on the flash drive which is the shutdown equivalent to the config/go file used during startup.  I have always thought that an empty version of this file (which contains nothing but a comment) should be provided as standard to make it more easily discoverable.

config/stop runs very early in the shutdown process -- not sure if you meant to quote me where I said "To run things LATE in the shutdown process is hard" there, but it holds true. It works great for various full-stack cleanup, or external notifications/hooks, but is technically not the best place for commands that affect the status of the server hardware (like my much earlier posts about turning the AC power off at the plug).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.