CygwinX at MS Terminalserver?

Jon TURNEY jon.turney@dronecode.org.uk
Fri Aug 27 16:32:00 GMT 2010


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 [1], 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 [2] 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.

[1] http://x.cygwin.com/devel/todo.html
[2] 
http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.0-displayfd.patch

>>> 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
>>
>> mkdir /var/log/xwin
>> 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.

-- 
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/



More information about the Cygwin-xfree mailing list