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.
It seems like the process gets the USR1 signal before it
starts to pause(). Is our Xserver too fast?
I have verified this to occur on occasion but not consistently. This
has been assigned to a developer for further review.
I logged an identical bug. You probably want to find it and mark it as
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.
*** Bug 2621 has been marked as a duplicate of this bug. ***
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
Can you reproduce?? If not tell me ASAP and I will be more
------- 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.
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
*** 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
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.
Fixed in errata XFree86-*-52 release.