[Solved] reliable way to run post-suspend jobs?

[GNUser]

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:

Code: [Select]

#!/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?

[Rich]

Hi GNUser
When you execute this:

Code: [Select]

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?

[GNUser]

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?

[Rich]

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.

[curaga]

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.

[GNUser]

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:

Code: [Select]

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:

Code: [Select]

#!/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?

[GNUser]

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:

Code: [Select]

#!/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.

[jazzbiker]

Thanks, guys! Sheer brilliant! Goliath shut down with a pinpoint! Sorry for offtopic, couldn't hide excitement...

[Rich]

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:

Code: [Select]

# 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

[GNUser]

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.)

[Rich]

Hi GNUser
Ah, I missed the  sed  command. Well done.