Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 2402 - annoying timeout when in xinit (server too fast?)
annoying timeout when in xinit (server too fast?)
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: David Lawrence
: 2621 3448 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 1999-04-28 16:50 EDT by redhat-bugzilla
Modified: 2008-05-01 11:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-06-17 10:53:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description redhat-bugzilla 1999-04-28 16:50:35 EDT
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 17:30:59 EDT
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 09:05:59 EDT
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 11:32:59 EDT
*** 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
second timeout

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

------- Additional Comments From chris@ferret.lmh.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 12:47:59 EDT
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
Comment 5 Jeff Johnson 1999-06-14 10:19:59 EDT
*** 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.
Comment 6 Bill Nottingham 1999-06-17 10:53:59 EDT
Fixed in errata XFree86-*-52 release.

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