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.
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.
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...
There may have been changes in how the X server implements VT switching, then. There certainly haven't been any in vlock...