Run a script as the last thing during shutdown

[gilphilbert]

Long time user, first actual post!

I will be executing exitcheck.sh as part of a service that will bring down a Tiny Core system. Once the system is safely down (file systems unmounted, etc.) I want to execute a couple of commands before the actual power down - essentially to send a GPIO message - as the absolute last thing that happens.

I've been studying /opt/shutdown.sh and /etc/init.d/rc.shutdown but I can't work out what happens after them. Since TC is BusyBox, I know there are no standard runlevels, so I can't use /etc/rc.0 for example. Can anyone help with how I can run a script as the very last thing to happen?

Thanks!

[Rich]

Hi gilphilbert
Welcome to the forum.

I think the sequence of events is:
exitcheck.sh poweroff -> /opt/shutdown.sh -> /sbin/poweroff -> /etc/inittab -> /etc/init.d/rc.shutdown

... Once the system is safely down (file systems unmounted, etc.) I want to execute a couple of commands before the actual power down - essentially to send a GPIO message - as the absolute last thing that happens. ...

I think that might not work. Where will you load the commands from if all of the file systems are unmounted?

[gilphilbert]

I think the sequence of events is:
exitcheck.sh poweroff -> /opt/shutdown.sh -> /sbin/poweroff -> /etc/inittab -> /etc/init.d/rc.shutdown

Is it acceptable to have an extension modify those scripts? I'm new to creating my own extensions and I'm trying to work out what's deemed "acceptable" for an extension to do. I'm guessing I would have to add my command to /etc/init.d/rc.shutdown and make sure that script is added to /opt/filetool.lst so the changes are persisted.

... Once the system is safely down (file systems unmounted, etc.) I want to execute a couple of commands before the actual power down - essentially to send a GPIO message - as the absolute last thing that happens. ...

I think that might not work. Where will you load the commands from if all of the file systems are unmounted?

OK, that was stupid, I accept that 

[curaga]

That would be out of line for an extension in the repo, but for your private ones, anything goes. Though for modifying base scripts, the preferred method is remastering (or adding another initrd, if your bootloader supports that).

[Rich]

Hi gilphilbert

Is it acceptable to have an extension modify those scripts? ...

For an extension you intend to submit to Tinycore, I would say no.
For a personal extension, sure. Tinycore is a toolkit you can modify to fit your needs.

... I'm guessing I would have to add my command to /etc/init.d/rc.shutdown ...

You could, but where would you place your commands?  rc.shutdown  goes something like this:

Code: [Select]

1. Sync filesystems                        # No problems here.
2. Disable swap space                      # No problems here.
3. Kill all processes                      # Maybe a problems here, could kill a needed daemon.
4. Unmount all extensions                  # Problem if your commands will depend on an extension.
5. Delete extensionssions being updated    # Problem if your commands will depend on those extensions.
6. Unmount tce directory                   # Problem if your commands will depend on the tce directory.
7. Unmount backup directory                # Problem if your commands will depend on the backup directory.
8. Unmount everything else                 # Problem, no place to run commands from.

exitcheck.sh poweroff -> /opt/shutdown.sh -> /sbin/poweroff -> /etc/inittab -> /etc/init.d/rc.shutdown

poweroff  basically just tells  inittab  to run  rc.shutdown, so you can ignore those 2.

I would use  /opt/shutdown.sh  because it's already included in your backup and that's what it's there for.
Place this at the end of  /opt/shutdown.sh:

Code: [Select]

sync

Code: [Select]

sleep 1

Code: [Select]

syncThis will force all writes to storage devices to complete. Then place your commands after that.

... OK, that was stupid, I accept that

Not really, considering the context:

... Once the system is safely down (file systems unmounted, etc.) ...

The first thing that comes to mind is data preservation, not can I still run a command.

[gilphilbert]

Thanks for the help here, it's really appreciated

I suspected that changing system scripts wouldn't be smiled upon. I don't like the idea of doing it either - even for personal scripts it feels a bit... hacky. The problem is that my command will cut power to the device, so nothing else will (ever) be run after that command. This is why I want it to be at the end of the shutdown process.

Thinking about the problem differently, I could use the gpio-poweroff overlay in config.txt, which should work for my purposes. It's not ideal, but I can make it work. That said, now I need to modify that file... again, not ideal. My script includes a configuration portion that would need to mount the boot filesystem, edit config.txt and then umount it. I don't suppose that would be accepted into the repos?

[Paul_123]

So your talking Raspberry pi.

The gpio-shutdown overlay can be used to handle the shutdown event activities,  Then the gpio-poweroff will change the state of a gpio pin after system halt (And I believe after the 10 flashes of the power LED to indicate the system is down.

We won't be enabling things like that in our standard images.   It feels like you just need to make your own images.

To curaga's point above.  The Raspberry pi bootloader supports multiple initrd's, we already supply two in the RPi images.   So you can easily concatenate a third initrd in the config.txt.   The only catch is that the initramfs line has to be 80 characters or less.

[gilphilbert]

Actually, I would rather this applied to any single board computer rather than just the Raspberry Pi. I was just trying to think outside of the box for a moment.

I've built a hardware device - a power manager for single board computers. One of the things it does it cuts off power to the board when a given pin goes high (usually at the end of the shutdown sequence). For systemd-based systems, this is achieved with a script that runs at the very end of the halt process - meaning it will work with not just Raspberry Pi OS, but also with Armbian, etc. to support any SBC that has GPIOs (which is all of them). I'm currently using it with a Raspberry Pi and a NanoPi Neo and it works perfectly, but TCL has got me stumped because - not unreasonably - it's hard to add something to the very end of the shutdown sequence that doesn't require custom builds.