This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 127318 - $LOCK_X nonfunctional in apmscript probably due to typo or changed fields in /usr/bin/w
$LOCK_X nonfunctional in apmscript probably due to typo or changed fields in ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: apmd (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Zdenek Prikryl
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-06 12:45 EDT by Jesse Glick
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 09:32:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jesse Glick 2004-07-06 12:45:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

In my stock /etc/sysconfig/apm-scripts/apmscript there is the
following block of code, run if $LOCK_X is set and a few other
conditions hold:

w |tail +3 |awk '{print $1, $3}'| LC_ALL=C grep -v '-'| LC_ALL=C grep
: | \
sort -u | \
while read line; do
    # SOME STUFF HERE
done

But if I run a kernel with APM support and set

LOCK_X="yes"

in /etc/sysconfig/apmd, my X display is *not* locked. (Suspension
works fine.)

Investigation showed that the pipe command here was returning no rows.
In fact /usr/bin/w shows

 12:39:00 up 30 min,  1 user,  load average: 0.11, 0.28, 0.33
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
jglick   :0       -                12:16   ?xdm?   1:58   0.70s
/usr/bin/gnome-

which is consistent with the man page which says

The  following entries are displayed for each user: login name, the
tty name, the remote host, login time, idle time, JCPU, PCPU, and the
 command line of their current process.

Hannu Martikka's patch is thus extracting the (useless) FROM field and
ignoring the TTY field. If you change the second extracted field to be
$2 rather than $3, thus:

w |tail +3 |awk '{print $1, $2}'| LC_ALL=C grep -v '-'| LC_ALL=C grep
: | \
sort -u | \
while read line; do
    # SOME STUFF HERE
done

then I can confirm that this block of code, run in isolation by root,
does lock my Gnome session's X display correctly.

(I tried using this patch together with $LOCK_X. Without the patch,
apm -s works but does not touch the X screen saver. With the patch, my
screen blanked but my laptop, a Toshiba Tecra 9000, did not suspend,
the cooling fan stayed on high, and the machine was unresponsive to
all input, forcing me to do a hard reboot. I have no idea what might
have been wrong here; perhaps some machine-specific bug. But someone
else may be able to confirm that the change works as desired.)

Version-Release number of selected component (if applicable):
apmd-3.0.2-22

How reproducible:
Always
Comment 1 Jesse Glick 2004-07-06 12:55:27 EDT
Another note about my last comment re. a hang after using the patch: I
do use a wrapper script which invokes "xscreensaver-command -lock
-display :0" before running "apm -s", and this works fine almost all
of the time, without needing to set $LOCK_X in /etc/sysconfig/apmd.
(About one time in ten after resuming, the xscreensaver unlock screen
does not appear - I see the contents of my Gnome desktop but no X
input events work - which can be worked around using "killall -HUP
xscreensaver" from a virtual console.) But the code in apmscript (for
Gnome) is significantly more complicated.

Note You need to log in before you can comment on or make changes to this bug.