X: Authorization required, but no authorization protocol specified

[Markus Hoenicka]

Hi,

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


waiting for X server to begin accepting connections 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/markus.hoenicka/.serverauth.324

.
..
..
..
..(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more
information
LoadPreferences: /home/markus.hoenicka/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
winDetectSupportedEngines - Returning, supported engines 00000005
winSetEngine - Multi Window or Rootless => ShadowGDI
winScreenInit - Using Windows display depth of 32 bits per pixel
winAllocateFBShadowGDI - Creating DIB with width: 2960 height: 1050
depth: 32
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24
bpp 32
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to lack
of shared memory support in the kernel
glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
(II) AIGLX: Testing pixelFormatIndex 1
GL_VERSION: 2.1.0 - Build 8.15.10.2869
GL_VENDOR: Intel
GL_RENDERER: Intel(R) 4 Series Internal Chipset
(II) AIGLX: enabled GLX_SGI_make_current_read
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
(II) AIGLX: enabled GLX_SGIX_pbuffer
(II) 51 pixel formats reported by wglGetPixelFormatAttribivARB
(II) AIGLX: Set GLX version to 1.3
(II) 6 fbConfigs
(II) ignored pixel formats: 0 not OpenGL, 6 RBGA float, 3 RGBA unsigned
float, 0 unknown pixel type, 36 unaccelerated
(II) GLX: Initialized Win32 native WGL GL provider for screen 0
winPointerWarpCursor - Discarding first warp: 1480 525
(--) 3 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) Windows keyboard layout: "00000407" (00000407) "German", type 4
(--) Found matching XKB configuration "German (Germany)"
(--) Model = "pc105" Layout = "de" Variant = "none" Options = "none"
Rules = "base" Model = "pc105" Layout = "de" Variant = "none" Options =
"none"

winInitMultiWindowWM - DISPLAY=:0.0
winMultiWindowXMsgProc - DISPLAY=:0.0
winProcEstablishConnection - winInitClipboard returned.
Authorization required, but no authorization protocol specified
.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.
.
Authorization required, but no authorization protocol specified
..
Authorization required, but no authorization protocol specified
..
Authorization required, but no authorization protocol specified
..
Authorization required, but no authorization protocol specified
..
Authorization required, but no authorization protocol specified


These messages pop up forever until I kill the server. No X client is
started, and I can't start any other from the systray X menu either
(this just gives additional authorization error messages).

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.

.startxwinrc looks like this:

$ cat .startxwinrc
exec sleep infinity

and has these permissions:

$ ls -al .startxwinrc
-rw-rwxr--+ 1 myuser mygroup 51 Aug 6 16:34 .startxwinrc

Some enviroment variables:

$ echo $CYGWIN


$ echo $DISPLAY
:0.0

As a workaround I can start XWin manually like this:
/usr/bin/XWin :0 -multiwindow

However, I suppose the default behaviour of startx and startxwin was not
intended to perform like this. Did I miss something obvious?

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

[Jon TURNEY]

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.

--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

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

[Markus Hoenicka]

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

[cyg Simple]

On 8/10/2015 3:41 AM, Markus Hoenicka wrote:
> At 2015-08-07 11:26, Jon TURNEY was heard to say:
>>
>> 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>
>

Corinna made changes which invalidates this value form for HOME existing
in Windows environment. We've been arguing against the change. This is
another example of why it should be left the way it has worked since day 1.

--
cyg Simple

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

[Markus Hoenicka]

Am 2015-08-10 15:13, schrieb cyg Simple:
> On 8/10/2015 3:41 AM, Markus Hoenicka wrote:
>> At 2015-08-07 11:26, Jon TURNEY was heard to say:
>>>
>>> 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>
>>
>
> Corinna made changes which invalidates this value form for HOME
> existing
> in Windows environment. We've been arguing against the change. This
> is
> another example of why it should be left the way it has worked since
> day 1.
>

I've noticed the discussion about those changes, but I don't fully
understand the impact of them (and hopefully I don't have to). But I
don't think my problem argues against Corinna's changes because HOME
does not exist in my Windows environment. HOMEDRIVE and HOMEPATH exist
though. I suppose HOME is set by some scripts in /etc as the docs
suggest.

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

[Achim Gratz]

Markus Hoenicka <markus.hoenicka <at> mhoenicka.de> writes:
> I've noticed the discussion about those changes, but I don't fully
> understand the impact of them (and hopefully I don't have to). But I
> don't think my problem argues against Corinna's changes because HOME
> does not exist in my Windows environment. HOMEDRIVE and HOMEPATH exist
> though. I suppose HOME is set by some scripts in /etc as the docs
> suggest.

So what are these environment variables set to and what is the value of
$HOME? I don't see how what you've described could result in the windows
path for $HOME that you've shown. Additionally, the location of the
.Xauthority file suggests that $HOME has a different value when this file
gets created and somehow has changed later when you try to start an X
application.


Regards,
Achim.




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

[Markus Hoenicka]

At 2015-08-10 15:44, Achim Gratz was heard to say:
> Markus Hoenicka <markus.hoenicka <at> mhoenicka.de> writes:
>> I've noticed the discussion about those changes, but I don't fully
>> understand the impact of them (and hopefully I don't have to). But I
>> don't think my problem argues against Corinna's changes because HOME
>> does not exist in my Windows environment. HOMEDRIVE and HOMEPATH exist
>> though. I suppose HOME is set by some scripts in /etc as the docs
>> suggest.
>
> So what are these environment variables set to and what is the value of
> $HOME? I don't see how what you've described could result in the
> windows
> path for $HOME that you've shown. Additionally, the location of the
> .Xauthority file suggests that $HOME has a different value when this
> file
> gets created and somehow has changed later when you try to start an X
> application.
>

set|more in a DOS box shows:

HOMEDRIVE=C:
HOMEPATH=\Users\<username>

I don't know if these are relevant if you use roaming profiles though.
The path I've shown as $HOME is not arcane at all. In a windows exlorer,
this is something like H:/My Documents/home/<username>. But why do you
think that HOME can be subject to changes during a session? And why does
it *not* change if I set HOME to a local drive?

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

[Markus Hoenicka]

At 2015-08-10 16:11, Markus Hoenicka erred:
> And why does it *not* change if I set HOME to a local drive?

s/HOME/XAUTHORITY/

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

[Achim Gratz]

Markus Hoenicka writes:
> HOMEDRIVE=C:
> HOMEPATH=\Users\<username>
>
> I don't know if these are relevant if you use roaming profiles
> though. The path I've shown as $HOME is not arcane at all.

You still haven't shown what $HOME is set in Cygwin, only what path it
maps to on Windows.

> windows exlorer, this is something like H:/My
> Documents/home/<username>.

I've figured as much, but I don't understand what you did to get it
pointing there. Do you mount something to /home/markus.hoenicka in
/etc/fstab or /etc/fstab.d/markus.hoenicka perhaps? Where do you have
Cygwin installed?


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

[Markus Hoenicka]

At 2015-08-10 18:11, Achim Gratz was heard to say:
> Markus Hoenicka writes:
>> HOMEDRIVE=C:
>> HOMEPATH=\Users\<username>
>>
>> I don't know if these are relevant if you use roaming profiles
>> though. The path I've shown as $HOME is not arcane at all.
>
> You still haven't shown what $HOME is set in Cygwin, only what path it
> maps to on Windows.
>
>> windows exlorer, this is something like H:/My
>> Documents/home/<username>.
>
> I've figured as much, but I don't understand what you did to get it
> pointing there. Do you mount something to /home/markus.hoenicka in
> /etc/fstab or /etc/fstab.d/markus.hoenicka perhaps? Where do you have
> Cygwin installed?

$HOME is as simple as can be, and now that you mention it, I do use an
entry in /etc/fstab to put /home where it is:

$ echo $HOME
/home/<username>

$ cat /etc/fstab
# For a description of the file format, see the Users Guide
# http://cygwin.com/cygwin-ug-net/using.html#mount-table

# This is default anyway:
none /cygdrive cygdrive binary,posix=0,user 0 0
//<serverpath>/home/<username>/Eigene\040Dateien/home /home ntfs
acl,binary,user 0 0

Cygwin itself is installed on the local drive, in C:/cygwin64

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

[Andrey Repin]

Greetings, cyg Simple!

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

> Corinna made changes which invalidates this value form for HOME existing
> in Windows environment. We've been arguing against the change. This is
> another example of why it should be left the way it has worked since day 1.

You're confusing yourself and those around you.
Corinna discussed the changes that may invalidate passing networked %HOME%
from Windows to Cygwin, but not Cygwin's own setting of $HOME to a network
location.


--
With best regards,
Andrey Repin
Monday, August 10, 2015 16:33:15

Sorry for my terrible english...


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

[Markus Hoenicka]

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 this be a timing issue while writing to a network drive? Remember
that we use roaming profiles here.

In any case, starting additional X applications still does not work,
even in the presence of that .serverauth.XXXX file. Trying to start
another xterm from the X systray menu results in:

executing 'xterm', pid 1316
(pid 1316 stderr) Authorization required, but no authorization protocol
specified
(pid 1316 stderr) xterm: Xt error: Can't open display: :0.0

So, for some reason, the existence of both .Xauthority and
.serverauth.XXXX in my $HOME is still not sufficient to start additional
X applications.

Remember that if I set XAUTHORITY to point to a file on my local disk
instead of letting startxwin pick a file in $HOME, the first X
application will always start up ok, and further X apps can be started
without any problems.

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

[Ken Brown]

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

[Markus Hoenicka]

At 2015-08-12 14:18, Ken Brown was heard to say:
> 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
>

I don't think so. If I use my workaround, the permissions are all the
same:

$ ls -al ~/.serverauth.4564
-rw-rwx---+ 1 <username> <group> 52 Aug 12 08:15
/home/markus.hoenicka/.serverauth.4564

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

[Jon TURNEY]

On 12/08/2015 07:22, Markus Hoenicka wrote:
> At 2015-08-07 11:26, Jon TURNEY was heard to say:
>> 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

> Could this be a timing issue while writing to a network drive? Remember
> that we use roaming profiles here.

Yes, I think that the fact it's a network drive is the significant
difference.

But the failure seems utterly crazy. xauth is used to write a file, and
then moments later another instance of xauth claims it doesn't exist.

I've no idea if this is a problem with xauth, cygwin or your networked
file system. Do you know what kind of device the network share is on?

There was another report of some problems with xauth and network file
system (see the thread starting at [1]), but the symptoms seem very
different. Nevertheless you might like to try with xauth -i to see if
the behaviour is any different.

Possible workarounds:

You could edit /usr/bin/startxwin to change 'enable_xauth' to 0, or set
the XAUTHORITY env var to a local path

[1] https://cygwin.com/ml/cygwin/2015-03/msg00398.html

--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

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

[Markus Hoenicka]

At 2015-08-12 17:21, Jon TURNEY was heard to say:
> On 12/08/2015 07:22, Markus Hoenicka wrote:
>> At 2015-08-07 11:26, Jon TURNEY was heard to say:
>>> 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
>
>> Could this be a timing issue while writing to a network drive?
>> Remember
>> that we use roaming profiles here.
>
> Yes, I think that the fact it's a network drive is the significant
> difference.
>
> But the failure seems utterly crazy. xauth is used to write a file,
> and then moments later another instance of xauth claims it doesn't
> exist.
>
> I've no idea if this is a problem with xauth, cygwin or your networked
> file system. Do you know what kind of device the network share is on?
>

I'm sorry but as a non-IT person I'm not familiar with the devices our
IT folks run.

> There was another report of some problems with xauth and network file
> system (see the thread starting at [1]), but the symptoms seem very
> different. Nevertheless you might like to try with xauth -i to see if
> the behaviour is any different.
>

I've added the -i switch to all xauth calls in startxwin, but that does
not make a difference except that the first attempt to start an X app
succeeds. As reported earlier, without the -i switch the *first* attempt
to start an X client fails, but a second try using the same command
usually succeeds. However, in either case I cannot run any other X
clients in addition to the first one.

> Possible workarounds:
>
> You could edit /usr/bin/startxwin to change 'enable_xauth' to 0, or
> set the XAUTHORITY env var to a local path
>

Yes, I've done the latter for the past couple of days, and this is
indeed all it takes to make X work again. As not many seem to be
affected by a similar setup, I think we should stop here looking for a
fix until further evidence suggests a solution.

thanks a lot
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