New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 903876 link

Starred by 3 users
Status: Fixed
Owner:
jkardatzke@chromium.org
Closed: Nov 16
Cc:
smbar...@chromium.org
█ reve...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Xwayland startup sometimes fails on display 0

Project Member Reported by jkardatzke@chromium.org, Nov 9 
I've seen this in the test results a couple of times now. The failure is in the screenshot for the x11_demo app and happens for both terminal and launcher mode. In the container's log you will see these lines:

Nov 04 22:16:02 penguin sommelier[141]: No protocol specified
Nov 04 22:16:02 penguin sommelier[141]: xdpyinfo:  unable to open display ":0".
Nov 04 22:16:02 penguin sommelier[141]: No protocol specified
Nov 04 22:16:02 penguin sommelier[141]: xrdb: Resource temporarily unavailable
Nov 04 22:16:02 penguin sommelier[141]: xrdb: Can't open display ':0'
Nov 04 22:16:02 penguin sommelier[141]: Child exited with status: 1

For more context:
Nov 08 22:35:44 penguin systemd[135]: Starting X11 sommelier at display 1...
Nov 08 22:35:44 penguin systemd[135]: Starting Master sommelier listening on socket wayland-1...
Nov 08 22:35:44 penguin systemd[135]: Starting Master sommelier listening on socket wayland-0...
Nov 08 22:35:44 penguin systemd[135]: Starting X11 sommelier at display 0...
Nov 08 22:35:44 penguin systemd[1]: Started CrOS SFTP service.
Nov 08 22:35:44 penguin systemd[135]: Started Master sommelier listening on socket wayland-1.
Nov 08 22:35:44 penguin systemd[135]: Started Master sommelier listening on socket wayland-0.
Nov 08 22:35:44 penguin sommelier[142]: _FontTransOpen: Unable to Parse address  /usr/share/fonts/X11/cyrillic
Nov 08 22:35:44 penguin sommelier[142]: _FontTransOpen: Unable to find transport for
Nov 08 22:35:44 penguin sommelier[142]: _FontTransOpen: Unable to Parse address  /usr/share/fonts/X11/Type1
Nov 08 22:35:44 penguin sommelier[142]: _FontTransOpen: Unable to Parse address  /usr/share/fonts/X11/100dpi
Nov 08 22:35:44 penguin sommelier[142]: _FontTransOpen: Unable to Parse address  /usr/share/fonts/X11/75dpi
Nov 08 22:35:44 penguin sommelier[139]: _FontTransOpen: Unable to Parse address  /usr/share/fonts/X11/cyrillic
Nov 08 22:35:44 penguin sommelier[139]: _FontTransOpen: Unable to find transport for
Nov 08 22:35:44 penguin sommelier[139]: _FontTransOpen: Unable to Parse address  /usr/share/fonts/X11/Type1
Nov 08 22:35:44 penguin sommelier[139]: _FontTransOpen: Unable to Parse address  /usr/share/fonts/X11/100dpi
Nov 08 22:35:44 penguin sommelier[139]: _FontTransOpen: Unable to Parse address  /usr/share/fonts/X11/75dpi
Nov 08 22:35:44 penguin systemd-resolved[133]: Positive Trust Anchors:
Nov 08 22:35:44 penguin systemd-resolved[133]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Nov 08 22:35:44 penguin systemd-resolved[133]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Nov 08 22:35:44 penguin systemd-resolved[133]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
Nov 08 22:35:44 penguin systemd-resolved[133]: Using system hostname 'penguin'.
Nov 08 22:35:44 penguin systemd-resolved[133]: Switching to system DNS server 100.115.92.193.
Nov 08 22:35:44 penguin sommelier[142]: No protocol specified
Nov 08 22:35:44 penguin sommelier[142]: xdpyinfo:  unable to open display ":0".
Nov 08 22:35:44 penguin sommelier[142]: No protocol specified
Nov 08 22:35:44 penguin sommelier[142]: xrdb: Resource temporarily unavailable
Nov 08 22:35:44 penguin sommelier[142]: xrdb: Can't open display ':0'
Nov 08 22:35:44 penguin sommelier[142]: Child exited with status: 1
Nov 08 22:35:44 penguin systemd[135]: Started X11 sommelier at display 0.
Nov 08 22:35:44 penguin systemd[135]: Started Chromium OS Garcon Bridge.
Nov 08 22:35:44 penguin garcon[208]: I1108 22:35:44.529941057     213 server_builder.cc:247]      Synchronous server. Num CQs: 1, Min pollers: 1, Max Pollers: 2147483647, CQ timeout (msec): 1000
Nov 08 22:35:44 penguin garcon[208]: [208]: Server listening on vsock port 1028
Nov 08 22:35:44 penguin systemd[135]: Started X11 sommelier at display 1.
Nov 08 22:35:44 penguin systemd[135]: Reached target Default.
Nov 08 22:35:44 penguin systemd[135]: Startup finished in 272ms.

Full logs here: https://stainless.corp.google.com/browse/chromeos-autotest-results/256164756-chromeos-test/

The failure appears like it is happening in Xwayland...but I'm nowhere near familiar enough with all of this yet to understand what's really happening yet. IIUC, Xwayland is creating the X server itself...and then connects to sommelier as the wayland compositor. So Xwayland should be creating the :0 display itself...which makes this failure really odd and it might just be a bug in Xwayland.  Due to the randomness, I would think it may also be some kind of startup race condition...but each sommelier instance is essentially independent...so the ordering there shouldn't matter (and in this case, the failing one was the last one to startup).

Comment 1 by jkardatzke@chromium.org, Nov 14 

This is not due to an issue with XWayland. This is a problem with the .Xauthority file. We startup 2 instances of sommelier-x and in their startup script we clobber the .Xauthority file. So there's a race between both of them for clobbering it and then writing to it with xauth.
Project Member

Comment 2 by bugdroid1@chromium.org, Nov 15 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/02c49fd6ee649d097cbf6f9ad0a4ca5cc360139f

commit 02c49fd6ee649d097cbf6f9ad0a4ca5cc360139f
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Thu Nov 15 21:16:10 2018

cros-sommelier: Don't erase .Xauthority file during startup

When I originally did this change, there was a discussion around using
'touch ~/.Xauthority' vs. using '>~/.Xauthority' and we determined the
latter was better because than if there was any corruption in the
.Xauthority file it would clean that up.  However, I've been seeing some
of the tests for the x11_demo app fail and I reproduced it locally and
noticed that the .Xauthority file was only 52 bytes instead of 104...and
it was missing the entry for the 0 display server. Since we are starting
up 2 instances of sommelier-x now (for low and high density) each of
them erases the .Xauthority file and then writes their entry. So we have
a clear race condition here.

It seems like it's a better option to assume that xauth itself will
clear up any issues with the .Xauthority file rather than having this
known race in there which will frequently cause issues.

BUG= chromium:903876 
TEST=Verified .Xauthority file is intact multiple times

Change-Id: Id05db53b8a53bb79e6b15c7cbc5103abd43ccb68
Reviewed-on: https://chromium-review.googlesource.com/1336407
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: David Reveman <reveman@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>

[modify] https://crrev.com/02c49fd6ee649d097cbf6f9ad0a4ca5cc360139f/cros-sommelier/BUILD
[modify] https://crrev.com/02c49fd6ee649d097cbf6f9ad0a4ca5cc360139f/cros-sommelier/sommelier-x@.service

Comment 3 by jkardatzke@chromium.org, Nov 16

Status: Fixed (was: Assigned)
►

Sign in to add a comment