[SOLVED] acpid "xscreensaver-command -lock" not working until acpid is restarted

TommyC7 · 06-29-2012, 12:03 AM

Sorry to bother everybody again, but I'm running into a mystery wrapped around a conundrum.

I believe this problem started with either yesterday (Wed Jun 27) or today's (Thu Jun 28) update (I'm running 64-current, did "slackpkg upgrade-all" ; "slackpkg install-new" and "slackpkg clean-system"). Again, I'm not 100% sure but it wasn't a problem during the Tue 26th update.

Anyways, here's the problem,
I've been using acpid to hibernate (when I push the power button) and lock my screen (when I close the lid on my laptop) for quite some time by setting my /etc/acpi/acpi_handler.sh:

Code:

#!/bin/sh
# Default acpi script that takes an entry for all actions

IFS=${IFS}/
set $@

case "$1" in
  button)
    case "$2" in
      power) /usr/sbin/pm-hibernate
         ;;
      lid) /usr/bin/xscreensaver-command -lock
	 ;;
      *) logger "ACPI action $2 is not defined"
         ;;
    esac
    ;;
  *)
    logger "ACPI group $1 / action $2 is not defined"
    ;;
esac

Nothing appears to be wrong with my /etc/acpi/events/default file either (output of grep -v ^# /etc/acpi/events/default):

Code:

event=.*
action=/etc/acpi/acpi_handler.sh %e

Unfortunately, despite all of this and reinstalling acpid (just in case my permissions were somehow messed up), my laptop still won't run "xscreensaver-command -lock" when I close the lid (and I also reinstalled xscreensaver). With the help of rworkman, we even confirmed that acpid is running with:

Code:

ps $(pidof acpid)

So even though the pm-hibernate command works with the power button (which is what I set it to), the "xscreensaver-command -lock" will not work with me closing the lid.

BUT!!!!!

1. "xscreensaver-command -lock" works fine on its own (me typing it in a virtual terminal)
2. restarting "acpid" via /etc/rc.d/rc.acpid restart DOES make the lid-closing method for "xscreensaver-command -lock" work successfully

I don't understand why #2 happens because acpid is running, started up by rc.M (I don't have a /proc/apm file either) and the power button for hibernate works. After all, if it was running and working successfully before without me changing anything, why would restarting it make it work?

The people of slackware's IRC channel on freenode said it may have to do with the events I've set, but as listed, the /etc/acpi/events/default file lists events=.* (and I've never touched the events folder) so I'm thinking it should pick up all events even if they have no command or action set to them.

TommyC7 · 06-30-2012, 03:40 AM

Ok, I believe I've found what is happening (I haven't looked into the technical details, so I'll just go based off of the error messages and such).

First off, when I added in "&> /someplace/screensaver.log" to the xscreensaver-command portion in /etc/acpi/acpi_handler.sh, I got:

Code:

xscreensaver-command: warning: $DISPLAY is not set: defaulting to ":0.0".
No protocol specified
xscreensaver-command: can't open display :0.0

So now I had something I could finally Google. All the Google results were about xhost, xauth and such. I didn't look too deeply to see when /etc/profile is called, but I'm guessing it's loaded after acpid.

My reasoning for this is because when acpid is loaded, I get that message above. However, when I do check my environment variables for root, $DISPLAY is set to ":0.0" so I still pondered why it didn't load. But, as stated in my first post, I could use "xscreensaver-command -lock" successfully as root after logging in (and restarting acpid would also make it work successfully). Hibernation and rebooting of course would cause the same error message to pop up again.

Eventually I came to believe that the $DISPLAY variable is set after acpid is loaded, although I have no idea why it was working before until I saw a .Xauthority file in /root. No idea why it wasn't working now, but after switching to a different user to run the "xscreensaver-command -lock" command in /etc/acpi/acpi_handler.sh, it was working again. I hope this helps other people, and if I'm wrong about the whole /etc/profile thing, then I'm out of ideas, folks.