Execute command after ACPI resume

Hello, I'm trying to lock my notebook whenever the screen lid is closed. I tried to combine /usr/bin/lock -vpn with ACPI control, by adding the lock command to /etc/rc.resume.

ACPI sleep/resume is working fine, but when the notebook is resumed, lock is not executed, and I'm back at the shell prompt. I'm using 10.2.

Is there a way to execute lock (or any other command) after an ACPI resume?
 
Hi.

Since suspend and resume is working for your notebook, you could try adding a devd(8) event to run a command when the lid is opened and the notebook resumes.
  1. Create a devd(8) configuration file in /usr/local/etc/devd/: # touch /usr/local/etc/devd/acpi_lock.conf
  2. Open the file in $EDITOR and add the following:
    Code:
    notify 10 {
    ## Opening lid : Lock the terminal
    match "system" "ACPI";
    match "subsystem" "Lid";
    match "notify" "0x01";
    action "/usr/bin/lock -vpn";
    };
  3. Save the file, restart the devd(8) service( # service devd restart), and try it out.
Note I have not tested this myself so it may or may not work for you.
 
Thanks for your reply. I've seen that the devd(8) rule is executed, but lock(1) is not. Actually even /etc/rc.resume is being executed, but lock seems to be exiting with status 1. I've found this out by adding the following to /etc/rc.resume:

Code:
...
/usr/bin/lock -pvn
/usr/bin/logger -t $subsystem "lock ret code $?"

So I'm assuming that lock needs some driver/resource that is not yet available when it's executed from /etc/rc.resume. I'm trying to find lock's source code to see what it could be. I'll update the post should I find something out.

As a workaround, I've created an alias for lock(1):

Code:
alias k="clear; /usr/bin/lock -vpn"

And call it before closing the lid. This way I get the desired functionality.
 
Hmm, it's possible the console just isn't completely up yet when the devd(8) action is executed. You could try adding a sleep(1) command to the rule and see if that helps, otherwise, if your happy with your workaround, great. :)
Code:
action "/bin/sleep 4; /usr/bin/lock -vpn";
If you have the FreeBSD source code installed, the source code for lock(1) is in /usr/src/usr.bin/lock
 
Instead of locking it when the lid opens you may want to lock it when the lid closes (just before it goes to sleep). On the lid open "event" there may be a small time delay before the lock actually executes, potentially providing an opening. It'll also resolve any ordering issues due to initialization when it's powering up.
 
Hey folks,
You can achieve executing commands when suspending the following way:
Add this line to your doas.conf
Code:
permit nopass root as yourusername

Then, in /etc/rc.suspend add this line:
Code:
env DISPLAY=:0 /usr/local/bin/doas -u yourusername /usr/local/bin/slock
I am using slock, so pick your own here.

I added this line after this part of the file:
Code:
/usr/bin/logger -t $subsystem suspend at `/bin/date +'%Y%m%d %H:%M:%S'`
/bin/sync && /bin/sync && /bin/sync
/bin/sleep 3

So yeah, new post after almost 8 years :) But I hope it will help someone, just like I was helped by vermaden on his post: https://vermaden.wordpress.com/2018...ey-components-locking-solution/#comment-25217

It worked on FreeBSD 13.1.
 
Hey folks,
You can achieve executing commands when suspending the following way:
Add this line to your doas.conf
Code:
permit nopass root as yourusername

Then, in /etc/rc.suspend add this line:
Code:
env DISPLAY=:0 /usr/local/bin/doas -u yourusername /usr/local/bin/slock
I am using slock, so pick your own here.

I added this line after this part of the file:
Code:
/usr/bin/logger -t $subsystem suspend at `/bin/date +'%Y%m%d %H:%M:%S'`
/bin/sync && /bin/sync && /bin/sync
/bin/sleep 3

Cool, however you don't need doas or sudo for this; /etc/rc.{suspend,resume} already run as root, so you can use su -l username -c $command instead, where $command could be
'env DISPLAY=:0 /usr/local/bin/slock'

So yeah, new post after almost 8 years :) But I hope it will help someone, just like I was helped by vermaden on his post: https://vermaden.wordpress.com/2018...ey-components-locking-solution/#comment-25217

It worked on FreeBSD 13.1.

cheers, Ian
 
Another way to achieve this is to use xidle to run the lock program. Taking 'slock' as an example, launch it using xidle as follows:-

xidle -se -program "/usr/local/bin/slock" -timeout 300 &

Which can be run from your desktop's autostart script, or .xinitrc.
Using wmaker I added the xidle command to ~/GNUstep/Library/Windowmaker/autostart .

To lock the screen on resume, add the line

pkill -USR1 xidle

to /etc/rc.resume, I added it after the filesystem sync as follows:-

/usr/bin/logger -t $subsystem resumed at `/bin/date +'%Y%m%d %H:%M:%S'`
/bin/sync && /bin/sync && /bin/sync
pkill -USR1 xidle

Which signals the xidle process on resume, causing it to invoke slock.

More information here:-

 
Of course you will have to re-patch /etc/rc.resume if that file gets over-written by an update. Can anyone suggest a better location to signal xidle from?
 
For bonus points, you can add a "lock" launcher to your desktop or root menu that uses the same pkill command to signal xidle.
 
In fact the approach of using devd suggested earlier in this thread is preferable, since it avoids patching a system script that might be updated.

So the final fix is to remove the pkill line from /etc/rc.resume, and instead we have

/usr/local/etc/devd # cat acpi_lock.conf
notify 10 {
## Opening lid : Signal xidle to lock the terminal
match "system" "ACPI";
match "subsystem" "Lid";
match "notify" "0x01";
action "/bin/pkill -USR1 xidle";
};

and you need to add
devd_enable="YES" to /etc/rc.conf,
and run "service devd restart"

It's worth checking /usr/local/etc/devd after an update to ensure the file acpi_lock.conf has survived.

Tested and working on my thinkpad X201.
 
Back
Top