This is the mail archive of the
cygwin-xfree
mailing list for the Cygwin XFree86 project.
Re: cygwin 1.7 startxwin failing due to "winMultiWindowXMsgProc - another window manager is running. Exiting."
- From: Jon TURNEY <jon dot turney at dronecode dot org dot uk>
- To: cygwin-xfree at cygwin dot com
- Cc: ofrijole at hotmail dot com
- Date: Tue, 14 Dec 2010 15:14:38 +0000
- Subject: Re: cygwin 1.7 startxwin failing due to "winMultiWindowXMsgProc - another window manager is running. Exiting."
- References: <4CF33DB3.2020805@hotmail.com>
- Reply-to: cygwin-xfree at cygwin dot com
- Reply-to: cygwin-xfree at cygwin dot com
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/