Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: GNUser on November 21, 2020, 09:57:05 AM
-
I am looking for a simple but reliable way of running pre- and post-suspend jobs.
Right now I have my Sleep Button bound to a shell script that looks like this:
#!/bin/sh
# pre-suspend jobs:
foo
bar
baz
sleep 1
# suspend:
sudo sh -c "echo mem >/sys/power/state"
# post-suspend jobs:
sleep 1
qux
quux
quuz
I've found that pre-suspend jobs run reliably but post-suspend jobs don't always run. Is there a better solution?
-
Hi GNUser
When you execute this:
sudo sh -c "echo mem >/sys/power/state"it's a signal to the operating system to enter the suspend mode. Doesn't the operating system provide a signal that it
has resumed normal operations that you can test for instead of using a sleep command?
-
Doesn't the operating system provide a signal that it has resumed normal operations that you can test for
That would be convenient, maybe there is such a thing. I'll keep looking.
Another (very unlikely) possibility is that the kernel knows to execute shell scripts in a particular directory when it resumes from suspend?
Also, maybe Busybox init or something else in the TCL base system has hooks for post-suspend jobs?
-
Hi GNUser
Depending on what the scripts are doing, it could be a driver that takes too long to wake up. Checking dmesg and
/var/log/messages after resuming would be useful in that case.
Well I learned something new today. qux and quux are not Linux programs, they're fake names like foo and bar.
-
This looks like a timing race? The suspend echo does not block, so the sleep and the first few commands may have executed by the time the system has suspended.
-
The suspend echo does not block...
Yes, that could explain the problems I'm having. I was assuming that the echo caused the system to suspend immediately.
Well, I found that the kernel logs something like this in /var/log/messages after the system wakes up:
Nov 21 13:17:50 t500 user.info kernel: ACPI: Low-level resume complete
So as long as the user doesn't need anything in /var/log/messages from before the suspend, something like this would get around the problem:
#!/bin/sh
# pre-suspend jobs:
foo
bar
baz
# suspend:
sudo rm /var/log/messages
sudo sh -c "echo mem >/sys/power/state"
# wait for system resume to be complete:
while true; do
grep -q "resume complete" /var/log/messages && break
sleep 0.1
done
# post-suspend jobs:
qux
quux
quuz
Do you guys foresee any problems with the above strategy?
-
It's also important to make sure that there is only one instance of the script running at a time, otherwise things can get chaotic.
So, assuming the script is called suspend-jobs , this is the final form of the script:
#!/bin/sh
# kill other instances of this script:
kill $(pgrep -f suspend-jobs | grep -v $$) 2>/dev/null
# pre-suspend jobs:
foo
bar
baz
# suspend:
sudo sed -i '/resume complete/ d' /var/log/messages
sudo sh -c "echo mem >/sys/power/state"
# wait for system resume to be complete:
while true; do
grep -q "resume complete" /var/log/messages 2>/dev/null && break
sleep 0.1
done
# post-suspend jobs:
qux
quux
quuz
Thread may be marked as "Solved". Thank you both very much.
P.S. If anyone can think of further improvements to boost reliability, please do share.
EDIT: I changed the script so that it doesn't delete /var/log/messages before suspending.
-
Thanks, guys! Sheer brilliant! Goliath shut down with a pinpoint! Sorry for offtopic, couldn't hide excitement...
-
Hi GNUser
... P.S. If anyone can think of further improvements to boost reliability, please do share.
EDIT: I changed the script so that it doesn't delete /var/log/messages before suspending.
So if you do suspend/resume and then do suspend/resume again, then this piece of code will succeed immediately
because it will find the resume complete message from the previous resume:
# wait for system resume to be complete:
while true; do
grep -q "resume complete" /var/log/messages 2>/dev/null && break
sleep 0.1
done
-
Rich, that will not be a problem. Note the sed command in the final form of the script (in Reply #6).
jazzbiker, I share your excitement. Other distros do seem to overcomplicate this sort of thing. (Actually, now that I'm used to TCL, other distros seem to be exercises in overengineering.)
-
Hi GNUser
Ah, I missed the sed command. Well done.