On 29/11/2010 05:44, Oly wrote: > Not sure when this started happening ... but sometime recently, starting the > xserver became a hit/miss proposition (mostly miss). I'm running Windows XP > Pro Service Pack 3 with the cygwin 1.7.7-1 and xorg-server 1.9.2-1 (as > reported by the setup wizard). I am using the installed x server start > shortcut which executes the following command: > > C:\cygwin17\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe > > The failure to start seems always to coincide with a log like the attached. > The interesting symptom is (from the bottom of the log): > > [214595.953] winMultiWindowXMsgProc - XOpenDisplay () returned and > successfully opened the display. > [214595.953] winMultiWindowXMsgProc - another window manager is running. > Exiting. > [214595.953] winClipboardProc - winClipboardFlushWindowsMessageQueue trapped > WM_QUIT message, exiting main loop. > [214595.953] winClipboardProc - XDestroyWindow succeeded. > [214595.953] winClipboardProc - Clipboard disabled - Exit from server > [214596.015] winDeinitMultiWindowWM - Noting shutdown in progress > > I've seen a nearly identical report on the forum about a year ago ... back in > the startxwin.bat days. The closest thing I found to a possible resolution was > the suggestion of inserting a sleep in the batch file. Not sure what might be > the trick now. > > For what it is worth, I notice consistent failure when I create an empty > .startxwinrc (to avoid the xterm opening - which I'd really like but could > live with closing it if the server started every single time). When I don't > have an empty .startxwinrc in my home directory ... failure is frequent, but > doesn't occur on every single start attempt. Failed 1 out of 2 tries tonight. > I deleted the log after stopping the server (right clicked the task tray icon > and chose exit) and the second start attempt failed. But sometimes it is the > first try. > > How could I figure out what is making the startup think some other window > manager is running? I don't think this is true - the failure occurs after a > clean reboot (and I don't have any auto-start stuff) ... but I also saw in > that previous thread something about a restart attempt (which may be borne out > by what I see in the attached log) ... maybe there *are* two managers due to > some race condition or something?
Thanks for the problem report. Yes, this is a race condition we haven't quite managed to stamp out. If you examine your log in detail, you'll see that around [214590.875] the X server is restarting, so there are duplicate calls to winInitMultiWindowWM() (which starts the internal WM) starting at [214590.437] and [214592.593] I imagine the sequence of events is something like: 1) startxwin starts 2) startxwin starts the X server 3) X server starts internal WM thread 4) startxwin tries to connect to X server and succeeds 5) startxwin runs commands from ~/.startxwin (empty) 6) startxwin disconnects from X server and exits 7) X server restarts at it has 0 clients connected 8) X server starts another internal WM thread 9) internal WM thread started in 3) connects 10) internal WM thread started in 8) connects, discovers a WM is already running and stops the whole server To properly fix this, we either need to introduce a mechanism which prevents external clients connecting before internal ones (which would be somewhat awkward to implement), or not create a internal WM thread every time the X server restarts (either properly checking for a still running one, or converting the existing thread into a long lived one which retries when it gets disconnected) As a workaround, I would suggest rather than an empty ~/.startxwinrc, simply create one which contains 'sleep 1', should hopefully avoid this problem for the time being. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
