This is the mail archive of the
mailing list for the Cygwin XFree86 project.
Re: CygwinX at MS Terminalserver?
On 16/08/2010 07:35, Steffen Sledz wrote:
Am 13.08.2010 13:09, schrieb Jon TURNEY:
Now testuser0002 tries to start another server in parallel.
This gives this error:
/usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X server instance is running on DISPLAY :0
This is expected. As I said, each X server instance must
have a unique display number.
This can't possibly work any other way. If two users both
have an X server with display number 0, to which server should
a client started with DISPLAY=:0.0 connect?
That's clear. I thought (or hoped) that starting X server using the "XWin Server" menu item automatically searches for an unused display number and uses it. I think that would be a good default behaviour.
I agree it would be useful, and it is on the todo list , but there's a
non-trivial problem to solve first:
How is the display number which the server has allocated communicated to other
processes, so that the users clients appear on the right display?
If you start the X server first and then launch everything from the traymenu,
everything would works fine, as the X server places a correct DISPLAY variable
into the environment inherited by the child process.
But if you start the X server via xinit/startx/startxwin, the display number
needs to be communicated back to xinit, so that the correct display number is
used for clients which are subsequently started by xinit.
Fedora ships with a patch  which adds the -displayfd option, which
allocates a display number and writes it to the specified fd. But to be
useful to us, xinit would needs some code to use that flag (under some
circumstances) and read that display number and use it for the clients it creates.
There's also the case where the user explicitly sets DISPLAY programmatically
or manually before starting clients. I think with some suitable shell
scripting, -displayfd probably can be used for that also.
A fatal error has occured and Cygwin/X will now exit.
Cannot open log file "/var/log/XWin.0.log"
This is interesting. On my systems, /var/log has mode 777,
rather than 1777.
Having the restricted deletion flag set on /var/log prevents
other users from deleting the logfile from a previous run.
However, checking the source for setup.exe, I see that it does
create /var/log with 1777 permissions, so how I got into this
state I don't know...
I'm not sure that is right, but assuming it is intentional, I
guess we need to create a /var/log/xwin with mode 777 and arrange
for that to be the default logfile location
chmod 777 /var/log/xwin
adding '-logfile /var/log/xwin/XWin.%s.log' to your xwin command line.
I tested this with success. :)
It would be very helpfully too if this can become the default behaviour of the "XWin Server" menu item (or XWin).
Well, it's not clear here how this should be fixed.
I *think* that this is just a setup bug, and we can simply create /var/log
with mode 777.
Volunteer Cygwin/X X Server maintainer
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html