ensuring ES gracefully finish ... annother approach

cyperghost

Hello fellows,
as @meleu did a really good job about the ensuring ES gracefully finish and save metadata in every system shutdown thing I did take annother approch.

In unix systems exists a nice service called incron - it's like cron but instead of time events the events of incron are file based.
Just Google about the possibilities it offers.

First you need to install incron, I have written a small installer for this.

Login as user Pi and go to home directory

cd ~
wget https://raw.githubusercontent.com/crcerror/icrontrol/master/setup.sh
wget https://raw.githubusercontent.com/crcerror/icrontrol/master/icrontrol.sh
chmod +x icrontrol.sh
sudo sh setup.sh

Now the incrontab for user pi opens

Just copy and paste this one to the tab and close it... then it automatically saves data as incron job.

/tmp IN_CREATE /home/pi/icrontrol.sh $#

This entry monitors file creations in folder /tmp ad calls script icrontrol.sh with created filename!

So we can catch up calls that were created by software and hardware
ES created three file that do some actions:

/tmp/es-restart, to restart the ES binary
/tmp/es-sysrestart, to reboot the whole system
/tmp/es-shutdown, to shutdown (poweroff) system

This files are recognized by incron and will be send to icrontrol.sh and there the action happens.

As I was in need to differ between hardware initiated shutdowns (buttonpress) and software initiated we can use and trigger events for buttons.

Like

button-restart >> to restart ES or finish an emulator via button press
button-sysrestart >> to reboot ES if maybe the power button is pressed for several seconds
button-shutdown >> to shutdown ES by button press

There are two ways to perform this.

Do it like ES and create a empty file with button-eventname in /tmp folder
Call the script icontrol.sh directly like /home/pi/icrontrol.sh button-restart

This calls or trigger-files HAVE TO BE created by your shutdown script. So instead of sudo poweroff write \home\pi\icrontrol.sh button-shutdown!

This is a great disadvantage as you have to alter the shutdown scripts but it gives you control back what happens before the shutdown sequence start.

For you @caver01 is the part relevant... as you can perform the GPIO calls for your transistor in the part of the icrontrol.sh case.

        es-shutdown)
            cleanup
            [[ -f "/tmp/action_hardware" ]] && exit
            touch /tmp/action_software && sleep 0.5

  # >>>>>>>>>>>>>> Insert here your coding in between <<<<<<<<<<<<<<<<<<<<
            # Should I call a script, trigger a GPIO??? ;) for example like this
            # Trigger Button for proper shutdown
            # sudo /home/pi/taster.sh 0
  # >>>>>>>>>>>>>> Insert here your coding in between <<<<<<<<<<<<<<<<<<<<

__

This script is not a competitor to @meleu s coding. It's just annother approach how shutdowns via software and GPIO can be performed without needing a script with a loop.

All in all I think that @meleu s solution is more generic and easier to maintain.
This script give the user maximum on flexibility but the user needs to be more in touch with unix systems to configure to his needs :)

I hope that both methods can be merged into a single one with no disadvantages and all benefits each method offers.

Have fun - Yours cyperghost
https://github.com/crcerror/icrontrol
Code via systemli
https://www.systemli.org/paste/?9337fcc2859f539e#qE169tTPGCScSYEcGZkYOfcQp7xMKTH0XF1R31vuvDE=

caver01

@cyperghost Interesting idea. Forgive me for not knowing the details here, but I have a question about ES: Are you saying that ES creates files in /tmp depending on the shutdown routine being executed?

cyperghost

@caver01 Simple Answer: Yes it does
And I use that files as trigger :)

caver01

@cyperghost Couldn't I simply embed my transistor trigger into a conditional to check for the files in my version of @meleu's killes.sh?:

if [[-f /tmp/es-restart || -f /tmp/es-sysrestart]]; then
# DO NOTHING, this is a restart not a shutdown
else
# ADD GPIO TRIGGER TO TRANSISTOR CODE HERE
fi

or are those files created by ES too short-lived which is why you are watching for them to get created? If I look at that ES script it looks like it drops

meleu

@caver01 it wouldn't work for any shutdown. And I'm afraid it wouldn't work in any case. And you guessed the reason: "those files created by ES too short-lived".

edit: as you can see in emulation.sh script, those files are removed right before calling reboot|poweroff, then killes.sh won't be able to see them.

caver01

@meleu Yeah, I knew we would gain just an inch more control over ES reboots only (it would still convert command line reboots via SSH, or reboots via RetroPie setup screens into shutdowns) but as I expected, it doesn't matter anyway because the files I would check are only there for a short time and removed before the shutdown/reboot command is sent.

Maybe there is some system-level "file" we can check using [[ -e FILENAME]]; to tell if it is in a reboot or shutdown cycle.

meleu

@caver01 the simplest solution I can think is to use a systemd trick again. Let's discuss on your thread to not mess this one.

cyperghost

@meleu said in ensuring ES gracefully finish ... annother approach:

@caver01 it wouldn't work for any shutdown. And I'm afraid it wouldn't work in any case. And you guessed the reason: "those files created by ES too short-lived".

edit: as you can see in emulation.sh script, those files are removed right before calling reboot|poweroff, then killes.sh won't be able to see them.

Correct - the files are not living to long to check via testcommand fileexistance!
Therefore the incron job triggers existance of files and gives feedback to script!
This works in any cases!

I did long testing with this and all files ... even if they were created and removed like

touch /tmp/testfile.dat && rm /tmp/testfile.dat

The script was always triggered. So YES this solution is working as else. But I was in need to use two more files... that give "feedback" what was triggered now?

Is it a shutdown via software? >> action_software-file is created and checked
Is it a shutdown via hardware? >> action_hardware-file is created and checked

So how does a software shutdown + GPIO triggering works?

Quit Menu -- ES Shutdown
ES creates file /tmp/es-shutdown
incron triggers script and realizes "action_software"
/tmp/es-shutdown is removed by ES shutdown script .... incron trigger is still active
incronscript triggers GPIO and set transistor to high
Now... the button shutdown script from Mausberry, bash, python... as you like is triggered (as a button press is recognizes)
This button shutdown script calls again the incron script /home/pi/incrontrol.sh button-shutdown
in the incrontrol.sh is a check for file ... "action_software" for usecase button-shutdown > Exit
in background the ES shutdown is still performed
GPIO is triggered, mausberry is off, regular shutdown performed

@meleu said in ensuring ES gracefully finish ... annother approach:

@caver01 the simplest solution I can think is to use a systemd trick again. Let's discuss on your thread to not mess this one.

As I said in OP ... the systemd trick is a general solution and seems easier to maintain.
But there are always many roads that leads to rome: Let us collect experience