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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=F1NuVS3tl5RLQn/X
	A1OfhPlosC9OKFuypSZdbPEexsxsSlMNLB3gsWPGXI+ZnWe/pCWdQPYVbMsf6Gff
	SAf6fO0QPgctEydhQWcz8cmTwr9rH69YY50piBkkPDQnwrLKEaK6Kc/t+4msHOzs
	ZDDjdrcUyTHY2tUogIPgEMRlq6U=
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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=3jlPk1TQaWj4S2xYXE7oaz
	YsBSM=; b=j5iWMXX+fqG6pwro6ZMgDCJLre25r1kYKarJd7x+TuqUQc423wQsbG
	WB1XTKwdLhHbHy4klzZLumF69x3DtymlcCWHtADtsOzuW45gvceu3O3fPVE/pFBD
	5lHIfMF+80XLQ8fuYZUKyEnHGFkUHZQo0/ESVqjLFdpm02cNRFxRg=
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.5 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO: limerock04.mail.cornell.edu
X-CornellRouted: This message has been Routed already.
Subject: Re: X: Authorization required, but no authorization protocol specified
To: cygwin AT cygwin DOT com
References: <67ea3d1202eccadc3fc21e58af6ca4bf AT mhoenicka DOT de> <55C479DA DOT 7000203 AT dronecode DOT org DOT uk> <114144297d60607a3c87f5fd63fb555a AT mhoenicka DOT de>
From: Ken Brown <kbrown AT cornell DOT edu>
Message-ID: <55CB3994.5060003@cornell.edu>
Date: Wed, 12 Aug 2015 08:18:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <114144297d60607a3c87f5fd63fb555a@mhoenicka.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

On 8/12/2015 2:22 AM, Markus Hoenicka wrote:
> 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.
>>
>>> 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.
>>
>>> 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?
>>
>> You might try modifying startxwin to remove the -q from xauth -q to
>> see if that reveals a bit more information.
>
> I finally got round to run this suggested test too. The first time I try
> to start X I get the following output:
>
> $ XAUTHORITY="" startxwin /usr/bin/emacs
> Using authority file /home/<username>/.serverauth.1076
> Writing authority file /home/<username>/.serverauth.1076
> Using authority file /home/<username>/.Xauthority
> Writing authority file /home/<username>/.Xauthority
> xauth:  file /home/<username>/.Xauthority does not exist
> xauth:  file /home/<username>/.Xauthority does not exist
> Using authority file /home/<username>/.Xauthority
> Writing authority file /home/<username>/.Xauthority
>
> Welcome to the XWin X Server
> Vendor: The Cygwin/X Project
> Release: 1.17.2.0
> OS: CYGWIN_NT-6.1 SBHC123 2.2.0(0.289/5/3) 2015-08-03 12:51 x86_64
> OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64)
> Package: version 1.17.2-1 built 2015-07-09
>
> XWin was started with the following command line:
>
> /usr/bin/XWin :0 -multiwindow -auth
>   /home/<username>/.serverauth.1076
>
> [...nothing interesting here...]
>
> cat: /home/<username>/.serverauth.1076: No such file or directory
> winProcEstablishConnection - winInitClipboard returned.
> winClipboardThreadProc - DISPLAY=:0.0
> OS maintains clipboard viewer chain: yes
> winInitMultiWindowWM - XOpenDisplay () returned and successfully opened
> the display.
> winMultiWindowXMsgProc - XOpenDisplay () returned and successfully
> opened the display.
> winClipboardProc - XOpenDisplay () returned and successfully opened the
> display.
> winMultiWindowXMsgProcErrorHandler - ERROR: BadMatch (invalid parameter
> attributes)
>
> ** (emacs:2996): WARNING **: Error retrieving accessibility bus address:
> org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.a11y.Bus
> exited with status 1
> Authorization required, but no authorization protocol specified
> Unable to init server: Could not connect: Abstract UNIX domain socket
> addresses not supported on this system
>
> (emacs:2996): Gtk-WARNING **: cannot open display: :0
> xinit: connection to X server lost
>
> [...normal shutdown sequence...]
>
> Emacs does not manage to open an X window during this process. I tried
> to spot .server* in a second MinTTY console during startup, but no such
> file would show up although xauth claims to have written the
> .serverauth.XXXX file.
>
> Now if I run exactly the same startxwin command a second time, Emacs
> *does* start up in an X window, although the startxwin output also
> claims this:
>
> cat: /home/<username>/.serverauth.2212: No such file or directory
>
> This time, the second MinTTY console confirms the presence of that file:
> $ ls -al .server*
> -rw-rwx---+ 1 <username> <group> 52 Aug 12 08:03 .serverauth.2212

Could the problem be related to the group permissions, possibly due to 
the ACL on your home directory?  Here's what I see on my system:

$ ll .serverauth.*
-rw------- 1 <username> <group> 156 2015-08-10 15:44 .serverauth.5968

Ken

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