ensuring ES gracefully finish and save metadata in every system shutdown

meleu

@yahmez said in ensuring ES gracefully finish and save metadata in every system shutdown:

@cyperghost
I thought this would work for any shutdown script? 😜

Yes. This is the intention of my approach here. ;)

I'm glad to know it's now working for you!

Have a nice weekend.

cyperghost

@yahmez Yes the solution from @meleu is working in general (thanks to him!)

... but I just want to take a look how the mass of these scripts are written. I'm currently working on annother way to shutdown and to give the user more control about the Pie.

One disadvantage will be that the shutdown scripts (bash, python or any other language) needs to be modified a bit. On the other hand, there will be no need to add something manually to systemd.

I don't know which method is better and I don't want to judge about. In the end the user decides on his own. The way how this script was born can be read on the first posting. And we can thank @meleu for his long breath and brillance in improve such scripts.

For me: It is always better to have two working ways ;)
Thanks for your help...

meleu

@BuZz do you think it would be valuable to add the trick described in the OP as an option in emulationstation.sh script module?

Summing up what it is: a way to ensure that ES will cleanly exit saving all metadata right before any shutdown/reboot.

If yes I can submit a PR for your evaluation.

EDIT: I'm thinking about an option like "Cleanly exit ES at any shutdown/reboot."

BuZz

@meleu It's an issue with 3rd party reboot scripts? Looking briefly at op, I don't see why this is needed in RetroPie (it's not a RetroPie problem).

meleu

@buzz said in ensuring ES gracefully finish and save metadata in every system shutdown:

@meleu It's an issue with 3rd party reboot scripts?

Not only 3rd party reboot scripts, but any shutdown method different than ES quit menu (example: "Perform reboot" on retropie_setup while ES is running, or shutdown -h now or reboot via SSH).

Looking briefly at op, I don't see why this is needed in RetroPie

Before the "Favorites/Last Played" feature was implemented, the "save metadata on exit" wasn't so important. But now it is. It can be really frustrating to lose your favorites after spending some time curating the list...

RetroPie doesn't actually need this, but it would avoid several topics here in the forum with people asking for help on how to not lose Favorites/Last played data when shutting down the pi with power buttons like Mausberry, Powerblock, etc.

(it's not a RetroPie problem)

Well, I have no intention to label it as a "RetroPie problem", but here is a 100% clean RetroPie use case (no custom configs/hacks involved):

Boot you raspi.
In ES add some games to Favorites.
Launch and exit some games (just to add some entries in the Last Played).
Launch retropie_setup via RetroPie Menu in ES.
Perform a reboot via retropie_setup.
After rebooting check that your Favorites/Last Played wasn't saved.

IMHO adding that trick as an option in emulationstation.sh script module has more pros than cons.

BuZz

@meleu Well my advice would be to not reboot from retropie-setup and use ES. Maybe I should add a warning about rebooting when launched from ES. 3rd party reboot scripts can easily kill and wait for ES first. I'm not keen to invade the init system with ES to handle reboot scenarios outside of ES.

meleu

@buzz OK, I got it. Let's leave this as a tinker trick. I'm going to add this topic to the "Useful topics" post.

cyperghost

@buzz Well you can add a file "es-sysrestart" to folder tmp and send SIGTERM to EmulationStation-binary PID only - then this script provided with ES will takeover the shutdown sequence. If no active ES-PID is available the usual system shutdown can be performed.

Of course a warning hint within RetroPie-setup is also considerable and needs no maintainment - just a bit of user brain :)

BuZz

@cyperghost Thanks. I am aware of that btw, I wrote that script :-)

Aphex

Being a owner of a NESPi Case (and Pi 3 model B), can i follow OP's guide as it is right now? or is there something else i should do/know about to make it work?
I've been trying to follow the whole thing but as a lesser-experienced linux user i still feel sorry to ask :s
EDIT: So sorry, i meant a NESPi Case, not RasPi

meleu

@aphex said in ensuring ES gracefully finish and save metadata in every system shutdown:

Being a owner of a RasPi Case (and Pi 3 model B), can i follow OP's guide as it is right now?

Yes. Let me know if you face some problem.

Aphex

@meleu After trying the guide with my NesPi case, i get the same initial result that @yahmez got. It's not saving changes and i also get the LED remains faintly lit (though i don't mind if it's fully off after 5 minutes).

@yahmez Have you performed extra modifications or anything to make it work? You posted this link ( https://pastebin.com/25GKw9xv ) but i am unsure of what to make of it.

Yahmez

@aphex The only thing I did was make the killes.service script executable. The code you linked is the shutdown script I am using. Although I am assuming you made the modifications to the NESPi as outlined in my PDF...

meleu

@yahmez said in ensuring ES gracefully finish and save metadata in every system shutdown:

The only thing I did was make the killes.service script executable

The script is killes.sh, and, yes, it must be executable. There's nothing wrong with the .service file. ;-)

Yahmez

@meleu
Ha, sorry. My error.

cyperghost

@meleu As I mentioned in my latest script!
To trigger ES events we can use incron job.

you can set it up as I done in my github script and maybe you can add a new user (afaik you are not using user PI on your system)

Then there can be two ways! To locate in which status ES shutdown now we have to use a kind of logger as incron just writes events to syslog....

So just write echo $# in incronjob results in an entry of syslog...

So we would write this to icrontab... maybe sudo?? sudo /etc/log.sh $#

/tmp IN_CREATE /etc/log.sh $#

log.shwill contain the redirection from incron

#!/bin/bash
# incron-logger to determine EmulationStation-quit-status
    esstatus=("es-restart" "es-sysrestart" "es-shutdown")

    for status in "${esstatus[@]}"; do
               [[ "$status" == "$1" ]] && echo "$1" > /etc/esstatus.log
    done

Important! That needs a bit of fine tuning! Because every file written will be logged! Unix uses tons of temporary files ;)
FIXED!

EDIT:

/tmp IN_CREATE cp $@$# /dev/shm/

would be much nicer ... then presence of ES status files have just to be tested ;) As these files are zero files, there is no chance to break copy process. And /dev/shm is "self cleaning" after shutdown ;)

Then we need to modify @meleu s script to determine the generated logfile and with this we can generate action based on ES-quit-status ;)

The solution I presnted yesterday lacks of speed, it works on a Raspberry 3 but maybe if the RPi 4 is available the shutdown is performed so fast my script will just terminated without action!

So I think systemd gots a more bright future.

@meleu
It's your turn now ;)
I hope that this gives you encourage to modify your script. Me and lot's of users will appreciate this. As I did not care about user rights managment, there maybe must be made sudo calls from time to time.

The king way would be to integrate the logger into the killes.sh and I vote for a rename of your script.... it sounds so destructive ;)

meleu

Hey bro. I appreciate your effort and I'm sure you're enjoying to learn all this stuff while working on your solution. Sadly I'm currently I'm away from my pi to test this stuff.

But let's just try to put very clear what problem we are trying to solve. As far as I understood we want to detect if the system is going to actually poweroff or just reboot. Is it right?

cyperghost

@meleu Yes...
Then we can set a trigger to this transistor GPIO

But what happens then? Will be a "second" shutdown performed? Because the triggered transistor will act as button press and call the regular shutdown script. Therefore I made a difference between software and hardware based actions ;) What's your opinion about?

What happens if you press shutdown button in ES? Then also a es-shutdown will be generated and the killes script will be triggered ;)

So you see it's a challenging game ;) And you see why the script from yesterday is so endless long. So yes, we need a to differ between shutdown and reboot and what initiated it? software or hardware.

The easiest solution seems to just to edit the emulationstation.sh and set the calls here but that's far away from generic solution.

But as final note:

Personally it's not my responsibility to offer scripts here and 
to satisfy someones setup. It's an encouragement to learn something 
new and to share this knowledge for free as volunteer.

Furthermore:
I see this as interaction between enthusiasts to make a great development even
better.

caver01

@cyperghost @meleu You guys are amazing! I really appreciate the work you put into this.

You guys have already vastly improved the button-triggered shutdown by re-writing the script to ensureES saves metadata. That alone is a very nice improvement. However, there has always been an unrelated problem with the Mausberry circuit: it simply ignores software shutdowns/reboots. In order for it to cut power it requires a physical button press. The fact that it ignores a reboot is fine--might even be designed that way. But software shutdown puts the circuit into a locked state and does not cut power.

For me, the goal was to fix a locking Mausberry circuit on soft shutdown. @meleu's service idea not only simplified the Mausberry script allowing us to revert back to the original version, but it also fixed the ES metadata problem for EVERY CIRCUIT OR SHUTDOWN SOLUTION. I love this because it takes the solution public, so to speak. It works no matter how you are triggering your shutdown.

Of course, it also gave me a place to insert something specific--a GPIO call to trigger my transistor. Doing so, now eliminates the Mausberry lockup problem. It does it at the expense of rebooting (make all reboots lead to poweroff), but this is a good compromise in my opinion.

If I could wrap that call inside a conditional to some system-level indicator to detect a shutdown (and ignore a reboot) my transistor trigger would be perfect.

@cyperghost's idea goes a long way toward detecting reboots from ES, but what about a reboot from the RetroPie config menus? What about SSH and a sudo reboot issued from commandline?

I love the ideas here. This puzzle has been a real challenge to enjoy! Thanks for all of the input.

cyperghost

OUTDATED: Take a look to this code piece

@caver01

but what about a reboot from the RetroPie config menus? What about SSH and a sudo reboot issued from commandline?

That's the issue I was working on. As long as you set a GPIO command in the killes.sh script as long it is triggered on every reboot and shutdown. A reboot is important... Just to test scripts and to test interaction.

So my bad workaround I would suggest is. Edit the /opt/retropie/supplementary/emulationstation/emulationstation.shand add something like

rm -f /tmp/es-shutdown && touch /dev/shm/es-shutdown

and then in killes.sh

[[ -f /dev/shm/es-shutdown ]] && trigger GPIO

That's the easiest way without installing additional services, but will work only for ES or you need to remember to add file es-sysrestart to location that needs to be detected and then perform a reboot.

Of course, it also gave me a place to insert something specific--a GPIO call to trigger my transistor. Doing so, now eliminates the Mausberry lockup problem. It does it at the expense of rebooting (make all reboots lead to poweroff), but this is a good compromise in my opinion.

Yes this solution is so far the best one - indeed!

If I could wrap that call inside a conditional to some system-level indicator to detect a shutdown (and ignore a reboot) my transistor trigger would be perfect.

That's my hope... Afaik reboot and poweroff use different runlevels to terminate programs. If there is a chance to detect runlevel for poweroff (0) or to detect runlevel for reboot (6) then there is a generel solution available.