X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:in-reply-to
	:references:message-id; q=dns; s=default; b=qvUofTaNExgRabiyTcfh
	5nz6UMRX3U1rkzg7YglXsJ4qgp0Ez0L9KLktRBrrT+sY0PKRIFWwqYy8SoyVNEmq
	6a6Ojvk+eEedWVY+wqnKsz0X6W1ou9VtazsLMfzCktvmrTMuSnowJ5T71UunghUk
	38lQrIOt2NueMeOvtkKTmrg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:in-reply-to
	:references:message-id; s=default; bh=0LQOORyPw6m+rMFFNdh6EKsLrY
	o=; b=TmfCJNeV5KL8r5jXajMJxeswxBXEuYvPbJdSpfOs544nJI9ILZRiBrxCTq
	bvs6MaKOTiIeOMYG8q169FNMFuo+E5Mc3VNpDPK7Z4tQDCn97tQAb8CFBRDSy25Y
	alKA7cDBdW/+rP3Z1nDQb0uMi38bKZGs0UTGEFCMgGA26eYJM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=no version=3.3.2
X-HELO: smtprelay05.ispgateway.de
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 10 Aug 2015 09:41:38 +0200
From: Markus Hoenicka <markus DOT hoenicka AT mhoenicka DOT de>
To: cygwin AT cygwin DOT com
Subject: Re: X: Authorization required, but no authorization protocol specified
In-Reply-To: <55C479DA.7000203@dronecode.org.uk>
References: <67ea3d1202eccadc3fc21e58af6ca4bf AT mhoenicka DOT de> <55C479DA DOT 7000203 AT dronecode DOT org DOT uk>
Message-ID: <7495b654b8e6ac58e74fcddf3aa07ed7@mhoenicka.de>
X-Sender: markus DOT hoenicka AT mhoenicka DOT de
User-Agent: Roundcube Webmail
X-Df-Sender: bWFya3VzLmhvZW5pY2thQG1ob2VuaWNrYS5kZQ==
X-IsSubscribed: yes

At 2015-08-07 11:26, Jon TURNEY was heard to say:
> On 06/08/2015 17:56, Markus Hoenicka wrote:
>> I've upgraded my setup yesterday and ran into a problem running the X
>> server. X ran just fine before the upgrade, just like any X client I
>> threw at it. I'm aware that some defaults have changed in the couple 
>> of
>> months since I upgraded, and I hope I've done everything the FAQ
>> recommends to accommodate these changes. However, no joy.
>> 
>> Starting the X server now is noticeably slower, regardless of how I
>> start it (Windows start menu, startx, or my hitherto preferred method
>> startxwin). Biggest problem though is that local X clients cannot
>> connect. The server output is like this:
>> 
>> $ startxwin /usr/bin/xterm
>> xauth:  file /home/markus.hoenicka/.Xauthority does not exist
>> xauth:  file /home/markus.hoenicka/.Xauthority does not exist
>> xauth:  file /home/markus.hoenicka/.Xauthority does not exist
>> xauth:  file /home/markus.hoenicka/.Xauthority does not exist
> 
> startxwin is just a shell script (based on the standard startx), which
> invokes xauth to add an authorization cookie to ~/Xauthority (which is
> also passed to the server using the -auth option)
> 
>> The file ~/.Xauthority is created during startup, and it is empty
>> after the server shuts down. It does not make any difference if I
>> remove the empty file before restarting the X server.
> 
> It should have some (binary) content while the server is running, but
> that seems to be failing to happen, for some reason.
> 

I forgot to mention that while the server is running there is indeed 
some binary content. The file is empty only after the server stopped.

>> As a workaround I can start XWin manually like this:
>> /usr/bin/XWin :0 -multiwindow
> 
> This works, of course, because this doesn't use -auth.
> 

Yes, I just thought I'd mention that in case someone bumps into the same 
problem. It might not be that obvious to the uninitiated.

>> However, I suppose the default behaviour of startx and startxwin was 
>> not
>> intended to perform like this. Did I miss something obvious?
> 
> Indeed.
> 
> Is there anything unusual about your home directory?
> 

Well, we use roaming profiles here at work. This has caused problems 
before, both in Cygwin and non-Cygwin apps. I've modified 
/usr/bin/startxwin like this:

$ diff /usr/bin/startxwin.orig /usr/bin/startxwin
138c138,139
<         XAUTHORITY=$HOME/.Xauthority
---
> #        XAUTHORITY=$HOME/.Xauthority
>         XAUTHORITY=/cygdrive/c/localdata/<username>/.Xauthority

i.e. it now uses a local drive to store .Xauthority. With this change, 
startxwin works without a hitch, and it is not any slower compared to 
before the upgrade. I don't know what is particularly broken about my 
$HOME as most Cygwin apps deal with it just fine:

$ cygpath -w $HOME
\\<serverpath>\home\<username>\Eigene Dateien\home\<username>

> You might try modifying startxwin to remove the -q from xauth -q to
> see if that reveals a bit more information.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple