Bug 68989 - "vlock & startx" no longer works
"vlock & startx" no longer works
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: vlock (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-16 15:07 EDT by James Ralston
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-07-16 15:08:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Ralston 2002-07-16 15:07:57 EDT
Description of Problem:

Up until Red Hat 7.3, I used to start my X11 session my typing:

    startx & vlock

This launched the X server in the background, and then immediately
locked the virtual console.

But under Red Hat 7.3, this command no longer works as expected: the X
server starts, but vlock loops asking for a password, consuming all
CPU time.

To reproduce:

1.  Make sure your login shell is /bin/bash.
2.  Login on virtual console 1.
3.  Execute "startx & vlock".
4.  After X has finished starting up, switch back to virtual console 1.

Actual Results:

vlock will be looping, asking for a password.

Expected Results:

vlock should be waiting for a password, without looping.

Additional Information:

I suspect that the updated version of bash (2.05a) shipped with Red
Hat 7.3 might be factor here, as it probably changed more between 7.2
and 7.3 than vlock did.
Comment 1 Michael K. Johnson 2002-07-16 15:12:01 EDT
startx & vlock creates a race for VT handling that there is no mechanism
to fix.  You were just lucky before...  You are correct that vlock has not
changed in ages.

This one blurs the semantic distinction between WONTFIX and NOTABUG, it
is perhaps LIMITEDBYDESIGN.

Sorry for the bad news.  Some strategic "sleep" commands might help get
you the effect you want.
Comment 2 James Ralston 2002-07-16 15:33:09 EDT
Alas, not even a longish sleep value avoids the race condition:

    startx & sleep 30; vlock

The only work-around I've found that works is to wait until the X server has
fully started, and then switch back to the virtual console and run "vlock" by
hand...
Comment 3 Michael K. Johnson 2002-07-17 16:25:36 EDT
There may have been changes in how the X server implements VT switching,
then.  There certainly haven't been any in vlock...

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