[Xquartz-dev] Autolaunched X11 doesn't work with fast-user-switching

[Merle Reinhart]

Your comments prompted me to play a bit more.

On the default Leopard X11, if I kill X11 (I would force quit it),  
the /tmp/.X*-lock file would remain behind.  Thus, the next time  
starting the server, it would create a new higher increment lock file  
as you described.

However, with the X11-2.1.1 package, killing X11 (again force quit)  
would remove the /tmp/.X*-lock file.

I don't know if this helps (I think I'm just confirming what you were  
saying), but there is definitely something different between the two  
versions on the death of the xserver.


Merle



On Dec 16, 2007, at 8:18 PM, Ben Byer wrote:

> This is odd -- on my system, starting up X11 using multiple users  
> logged in at the same time works just fine.  Then again, the  
> debugging printfs I added don't even seem to be running at all, so I  
> really have no idea what's happening on my Frankenstein-X11 system  
> -- I'll have to try this at work tomorrow.
>
> FWIW, .X0-lock is the lock file that corresponds with /tmp/.X11-unix/ 
> X0.  The server-main code is supposed to automatically find the  
> first available "normal display" number and use it.  Before, that  
> code was apparently too conservative (if it saw that socket there,  
> it assumed it was still active, and always picked the next display)  
> -- but this meant that if your X server died and you restarted it,  
> you'd end up with display :1 instead of :0.
>
> Now, it apparently doesn't correctly detect that the socket is still  
> active ... ever ...
>
> On Dec 16, 2007, at 1:45 AM, Jeremy Huddleston wrote:
>
>> I think the problem stems from our using the default lock file: / 
>> tmp/.X0-lock ... I don't see why the  original Leopard would've  
>> worked for you, so can you please check that out and verify?
>>
>> I'll try to fix this up as I rework the startup stuff... if you  
>> haven't already, would you mind filing a bug for it for me, so I  
>> don't forget?
>>
>> Thanks,
>> Jeremy
>>
>> On Dec 15, 2007, at 20:14, Merle Reinhart wrote:
>>
>>> The original Leopard X11 did not have this problem.  I don't have  
>>> a Leopard with the version just prior to X11-2.1.1 at this point  
>>> in time to determine if it was X11-2.1.1 where the problem  
>>> occurred or not (I can probably get there by the end of the  
>>> weekend).
>>>
>>> Merle
>>>
>>>
>>>
>>> On Dec 15, 2007, at 8:38 PM, Merle Reinhart wrote:
>>>
>>>> I've been doing a bit more testing with X11-2.1.1 and find that  
>>>> the autolaunching stuff doesn't work if one user already has the  
>>>> Xserver started.  At that point, any other user logging in via  
>>>> fast-user switching is not able to then use X11 (attempting to  
>>>> set DISPLAY to :1.0 and manually start X11.app winds up in an  
>>>> infinite loop with Xquartz still trying to talk to the server at : 
>>>> 0.0 which is owned by the other user).
>>>>
>>>> At this point in time, I have not been about to find a workaround  
>>>> that would allow more than one user to utilize X11.app at the  
>>>> same time.  Could this be because launchd is explicitly hard- 
>>>> coded to look at the :0 socket when the socket should increase  
>>>> based upon the number of logged in users?
>>>>
>>>> This is potentially a problem with multi-user systems where X11  
>>>> may be needed.
>>>>
>>>> Merle
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xquartz-dev mailing list
>>>> Xquartz-dev at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo/xquartz-dev
>>>
>>> _______________________________________________
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo/xquartz-dev
>>
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/xquartz-dev
>
> Ben Byer
> CoreOS / BSD Technology Group, XDarwin maintainer
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/xquartz-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2425 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20071216/1ae4d565/smime.bin