Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 128081

Summary: hibernate-script starts xlock the wrong way
Product: Gentoo Linux Reporter: Steffen Wolf <stw>
Component: New packagesAssignee: Mobile Herd (OBSOLETE) <mobile+disabled>
Status: RESOLVED UPSTREAM    
Severity: normal    
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Steffen Wolf 2006-03-30 00:16:18 UTC
sys-power/hibernate-script-1.12 has the following issues regarding xlock:

It doesn't find out the current user correctly when some unusual windowmanager is used (e.g. evilwm). One should add the process evilwm to the list of processes in the line "for xpid in `pidof ...`"

More important: It waits for xlock to finish, i.e. it waits until the user has typed in his password. On some machines the hibernate-script is started via acpid after some button event. On some machines these events produce an echo, causing acpid to call the script twice. There is a lockfile-mechanism to make sure that this doesn't lead to an unintentional suspend, but acpid waits for the hibernate-script to finish, which waits for the xlock to finish, which can lead to the behaviour that the computer suspends straight after the user enters the password for unlocking X.

Circumvention: Start xlock and detach it completely from the hibernate-script. The changes are:
- su $XUSER -c "xlock -mode blank &"
+ su $XUSER -c "xlock -mode blank &" >/dev/null 2>/dev/null

Simple as that. While one is at it, one can also move the starting of xlock to the before-suspend-block (change AddResumeHook 91 LockXlock to AddSuspendHook 91 LockXlock), this way it's impossible to catch a glimpse at the desktop before xlock is started.
Comment 1 Steffen Wolf 2006-03-30 00:17:11 UTC
*** Bug 128080 has been marked as a duplicate of this bug. ***
Comment 2 Henrik Brix Andersen 2006-03-30 01:41:32 UTC
Please report these issues upstream.