Noel David Torres Taño wrote:
Hello Bart:
Thanks for the tip. I've investigated a bit more.
I changed this:
--- /etc/acpi/lid.sh 2008-05-08 09:05:17.000000000 +0200
+++ /etc/acpi/lid.sh.orig 2008-05-08 08:52:01.000000000 +0200
@@ -7,10 +7,9 @@
. /etc/default/acpi-support
[ -x /etc/acpi/local/lid.sh.pre ] && /etc/acpi/local/lid.sh.pre
-echo `date` `whoami` >> /var/log/lid.sh.log
-if [ `CheckPolicy 2>>/var/log/lid.sh.log` = 0 ]; then echo "exiting" ; exit;
fi
-echo "going on"
+if [ `CheckPolicy` = 0 ]; then exit; fi
+
grep -q closed /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
to check what was happening. Then I changed permissions on /var/log/lid.sh.log
to allow world writing it, and closed and open the lid, and the
resulting /var/log/lid.sh.log was:
Thu May 8 09:07:29 CEST 2008 root
ERROR: Couldn't attach to DCOP server!
Thu May 8 09:07:31 CEST 2008 root
ERROR: Couldn't attach to DCOP server!
Thus the acpi script lid.sh runs as root (as it must to, being launched by
acpi), and that way it can not access user's DCOP server, thus "going on" and
locking the screen.
Further tests shown me I'm right. I launched /etc/acpi.lid.sh directly from
Konsole as both user and root. Outputs are:
[EMAIL PROTECTED]:/etc/acpi$ ./lid.sh
exiting
XXXXX:/etc/acpi# ./lid.sh
going on
With the matching lines in /var/log/lid.sh being:
jue may 8 09:10:43 CEST 2008 XXXXX
jue may 8 09:12:56 CEST 2008 root
ERROR: Couldn't attach to DCOP server!
Now that's definitely very interesting. I'll investigate a fix this
weekend, I probably don't have time earlier than that. There is already
some support in acpi-support for connecting to X desktops etc., and
apparently it's not being used here. I'll have to see if I can leverage
the existing support here as well.
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
