Bug 2402

Summary: annoying timeout when in xinit (server too fast?)
Product: [Retired] Red Hat Linux Reporter: redhat-bugzilla
Component: XFree86Assignee: David Lawrence <dkl>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 6.0CC: aleksey, chris, genec, sinsalaco
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: http://noa.tm/xinit-strace.txt
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-06-17 14:53:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description redhat-bugzilla 1999-04-28 20:50:35 UTC
When trying to start the X server in Hedwig with startx
i get a boring timeout before the windowmanager starts.
A strace of xinit (see url) shows that xinit sets an
alarm(15) and then pause()s. The relevant code in
xc/programs/xinit/xinit.c has the following comment:
----
/*
* kludge to avoid race with TCP, giving server time to
* set his socket options before we try to open it,
* either use the 15 second timeout, or await SIGUSR1.
*
* If your machine is substantially slower than 15 seconds,
* you can easily adjust this value.
*/
alarm (15);
pause ();
alarm (0);
----
It seems like the process gets the USR1 signal before it
starts to pause(). Is our Xserver too fast?

Comment 1 David Lawrence 1999-05-13 21:30:59 UTC
I have verified this to occur on occasion but not consistently. This
has been assigned to a developer for further review.

Comment 2 Chris Evans 1999-05-14 13:05:59 UTC
I logged an identical bug. You probably want to find it and mark it as
a duplicate.

Note that I _do_ see this consistently, if my X server and xinit and
WM etc. are all cached. I have a P2-350.

This is an annoying bug and probably warrants an update to fix.

Comment 3 Jeff Johnson 1999-06-03 15:32:59 UTC
*** Bug 2621 has been marked as a duplicate of this bug. ***

Hi

If I drop to runlevel 3 (no X running by default) then
startx is observed to be broken. Actually technically it is
"xinit" or the X server that is broken.

The broken behaviour is 15 seconds of waiting at a blank X
screen before my window manager is launched.

Closer inspection reveals that "xinit" is waiting for a
signal from the X server, which NEVER ARRIVES, hence a 15
second timeout

Can you reproduce?? If not tell me ASAP and I will be more
specific

------- Additional Comments From chris.ox.ac.uk  05/08/99 08:19 -------
Have some additional comments :-)

It appears to be a race condition. If I boot to runlevel 3 and type
"startx", my X session launches fine.

If I exit the X session, and type "startx" again, all the binaries are
cached and load very quickly. Because of this speed increase, the
race condition is observed - startx hangs for 15 seconds showing a
blank X screen.

Comment 4 Preston Brown 1999-06-08 16:47:59 UTC
I hopefully have coded up a fix for this, but we need to test it more
thoroughly before we roll it into the errata X release we are
planning.

Comment 5 Jeff Johnson 1999-06-14 14:19:59 UTC
*** Bug 3448 has been marked as a duplicate of this bug. ***

With RH 6.0 sometimes (maybe 1 time on 3) X takes 10 seconds
more to start (during these 10 seconds there's no disk
activity).
It happens with any window manager and I've seen it on 4
computers (they all use the SVGA server).
It's not a very severe bug, but's really annoying (usually X
takes only 3 or 4 seconds to start, why sometimes it has to
take 13 or 14?).
If you press ctrl+alt+backspace during the "slow" start and
then restart X, usually it start "fast".
It happens with any user on my system.

Comment 6 Bill Nottingham 1999-06-17 14:53:59 UTC
Fixed in errata XFree86-*-52 release.