Hide Forgot
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?
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 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.
*** 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@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.
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.
*** 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.
Fixed in errata XFree86-*-52 release.