Greeter and other clients cannot connect to X server

Sometimes, just after booting up, the graphical session does not start. It is a text display (in alt-f7) that ends in:

[ OK ] Reached target Graphical Interface

Photo available on request.

I add logs, including lightdm logs.

2013-10-19T13:49:07.284318+02:00 Minas-Tirith systemd[1]: Starting Graphical Interface. ******************************
2013-10-19T13:49:07.285038+02:00 Minas-Tirith systemd[1]: Reached target Graphical Interface.
2013-10-19T13:49:07.285868+02:00 Minas-Tirith systemd[1]: Starting Stop Read-Ahead Data Collection 10s After Completed Startup.
2013-10-19T13:49:07.286646+02:00 Minas-Tirith systemd[1]: Started Stop Read-Ahead Data Collection 10s After Completed Startup.
2013-10-19T13:49:07.287345+02:00 Minas-Tirith systemd[1]: Starting Update UTMP about System Runlevel Changes...
2013-10-19T13:49:07.288083+02:00 Minas-Tirith systemd[1]: Started Update UTMP about System Runlevel Changes.
2013-10-19T13:49:07.290187+02:00 Minas-Tirith systemd[1]: Startup finished in 6.182s (kernel) + 13.267s (userspace) = 19.450s.
2013-10-19T13:49:07.401875+02:00 Minas-Tirith dbus[544]: [system] Activating via systemd: service name='org.freedesktop.Accounts'
unit='accounts-daemon.service'
2013-10-19T13:49:07.414638+02:00 Minas-Tirith systemd[1]: Starting Accounts Service...
2013-10-19T13:49:07.446238+02:00 Minas-Tirith accounts-daemon[957]: started daemon version 0.6.34
2013-10-19T13:49:07.448784+02:00 Minas-Tirith dbus[544]: [system] Successfully activated service 'org.freedesktop.Accounts'
2013-10-19T13:49:07.449306+02:00 Minas-Tirith systemd[1]: Started Accounts Service.
2013-10-19T13:49:07.490808+02:00 Minas-Tirith xdm[551]: No protocol specified
2013-10-19T13:49:07.491487+02:00 Minas-Tirith xdm[551]: Error opening display! ******************************
Failure.
2013-10-19T13:49:07.494617+02:00 Minas-Tirith xdm[551]: No protocol specified
2013-10-19T13:49:07.495044+02:00 Minas-Tirith xdm[551]: /usr/bin/xrdb: Resource temporarily unavailable
2013-10-19T13:49:07.495408+02:00 Minas-Tirith xdm[551]: /usr/bin/xrdb: Can't open display ':0'
2013-10-19T13:49:07.498385+02:00 Minas-Tirith xdm[551]: No protocol specified
2013-10-19T13:49:07.498826+02:00 Minas-Tirith xdm[551]: /usr/bin/xmodmap: unable to open display ':0'
2013-10-19T13:49:07.544358+02:00 Minas-Tirith lightdm: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)

To recover, I issue init 3, init 5.

Machine is a laptop, compaq presario CQ61-330SS. Video is Intel GM45.

Created an attachment (id=564251)
Logs with the failure.

Happens nearly every-time here.

Assign to lightdm maintainer. From a quick look it looks like some kind of race condition where the X server comes up fine but neither the tools called from the Xsetup script nor the greeter can actually connect to it for whatever reason. When the greeter fails lightdm kills the X server and gives up.

Created an attachment (id=567304)
LightDM log

Created an attachment (id=567305)
Xorg log

Created an attachment (id=567306)
syslog

I think this thread in the support forum is this bug:
https://forums.opensuse.org/english/get-technical-help-here/install-boot-login/492295-13-1-xfce-fails-display-gui-login.html

Hi,

I found this problem in the final release openSUSE 13.1

There are two fixes (ugly fixes):

* After you boot the machine, change to console F1 or F2 with Alt+F1 or Alt+F2. Login as root and type this: init 5
  The display manager lightdm should run now.

* After you boot the machine, change to console F1 or F2 with Alt+F1 or Alt+F2. Login as root and edit the file /etc/sysconfig/displaymanager changing from lightdm to xdm. Restart the machine. Should work with the ugly xdm but works.

My machine is a MacBook Air 13" (6.2). openSUSE 13.1 works fine (I installed xfce instead gnome or kde). Now just I need to get the wifi card works too ;)

Regards

Following on from my comment #7 it may be significant that on the day that I installed 13.1 I restarted several times and did not get this problem. I was using an ethernet cable connection. The last thing I did on that day was configure wifi/networkmanager. The problem occurred the next morning when I started up with wifi switched on.

(It may also be significant that lxdm, which I'm now using instead, fails to unlock the login keyring. I'll raise another bug for that.)

Machine is a Thinkpad R60e - 32bit version of OpenSUSE.

Today I installed 13.1 xfce on a desktop without seeing this problem. No wifi or networkmanager on that machine.

Created an attachment (id=569153)
debug scripts

Can someone please extract the attached tarball in / and reproduce the problem? It will create
/etc/X11/xdm/X-wrapper
/etc/X11/xdm/Xsetup-wrapper
and overwrite
/etc/lightdm/lightdm.conf
Once you have reproduced the problem, please attach /var/log/lightdm/lightdm-xauth.log here.
After that you can delete the two scripts and reinstall lightdm in order to restore /etc/lightdm/lightdm.conf.

Created an attachment (id=569284)
lightdm-xauth.log as requested in comment #10

In my case I always get this problem. Every boot using XFCE or Gnome is the same.

Created an attachment (id=569418)
Attached the file requested

After uncompress the tar file the problem remains. I attached the file requested.

(In reply to comment #13)
> Created an attachment (id=569418) [details]
> Attached the file requested
>
> After uncompress the tar file the problem remains. I attached the file
> requested.

Thanks, that was just to see if the xauthority file was corrupt, but both yours and Davids are intact so that's not the reason for the failure to connect to the X server.
The problem here is that it is a race condition and I can't reproduce it neither on my laptop nor in a vm and there are many moving parts involved (lightdm, systemd, the xdm init script, X) and error reporting of X clients is pretty useless. I'm in contact with upstream about this.

Filed bug upstream. It would be helpful if those of you who can reproduce this subscribed to the upstream bug at https://bugs.launchpad.net/lightdm/+bug/1260220 so that additional information can be provided more easily if requested by upstream.

I'm the LightDM maintainer.

In Anibal's log it only shows the X server authority files and not the greeter authority files.

In David's logs it shows both, but in the "Before running X" stage the X authority has changed for some reason, and the greeter is continuing with the original X authority. If this is true they definitely couldn't connect.

Could you please re-try these tests and attach lightdm.log after this occurs? I need more information.

If the log doesn't give more information we might need to try a LightDM branch with some extra debugging added - would either of you be able to build from source / is there an easy way to make a package for testing Guido?

(In reply to comment #16)
> I'm the LightDM maintainer.
>
> In Anibal's log it only shows the X server authority files and not the greeter
> authority files.
>
> In David's logs it shows both, but in the "Before running X" stage the X
> authority has changed for some reason, and the greeter is continuing with the
> original X authority. If this is true they definitely couldn't connect.
>
> Could you please re-try these tests and attach lightdm.log after this occurs? I
> need more information.
>
> If the log doesn't give more information we might need to try a LightDM branch
> with some extra debugging added - would either of you be able to build from
> source / is there an easy way to make a package for testing Guido?

Yes, that's easily possible with OBS, please attach the debugging patches here and I'll make a package available.

Created an attachment (id=573726)
lightdm.log as requested

@Guido just a side note: as you could not reproduce the problem on your machines, have you upgraded from 12.3 or did a clean install? As I have reproduced the problem on three different machines now with a new install.

(In reply to comment #19)
> @Guido just a side note: as you could not reproduce the problem on your
> machines, have you upgraded from 12.3 or did a clean install? As I have
> reproduced the problem on three different machines now with a new install.

I always do clean installs (except when explicitly testing/triaging in vms), I also monitor OpenQA for Xfce runs and I've never seen it show up there either. So it probably boils down to a certain timing that triggers it.

Thanks Marcus,

The log looks normal.

The only part I can't see is what /etc/X11/xdm/Xsetup does. Is that standard OpenSUSE code or is there something custom in there? Is there any chance this could modify the xauthority files?

(In reply to comment #21)
> Thanks Marcus,
>
> The log looks normal.
>
> The only part I can't see is what /etc/X11/xdm/Xsetup does. Is that standard
> OpenSUSE code or is there something custom in there?

The openSUSE default Xsetup script only does some tweaks such as setting up the keyboard map, numlock and the screensaver, see http://susepaste.org/aaf896d9

> Is there any chance this
> could modify the xauthority files?

At least in case of the default script posted above, I don't think so.

Yes, I used the original Xsetup file.

Created an attachment (id=574091)
Another log

Another log.

Created an attachment (id=574092)
Another log

Created an attachment (id=574093)
Another log

Created an attachment (id=574094)
Another log x-0-greeter.log

I finally got one out of six of seven machines where the problem does not occur. This one has got a NVidia graphics card, the ones where the problem occurs are all Intel based. Not sure if that matters.

My laptop, where I have finally upgraded the main partition from 11.4 to 13.1, shows the problem now.

Initially, the system had "gdm". I switched to lightdm, and I have the issue often.

It is indeed Intel graphics (GM45).

*** Bug 848712 has been marked as a duplicate of this bug. ***

This also affects autologin, since no greeter is started it is the applications of the session that cannot connect to the X server rather than the greeter (see duplicate bug#848712), so the symptom there is that the session dies and one gets back to a greeter.

I'm one of the guys from bug#848712 who observe problems with autologin. BTW, that machine has the problem is fresh 13.1 install and has Intel graphics card as well.

@Robert it seems to be quite reproducable on Intel graphics cards. Do you perhaps got access to such a machine for direct debugging?

Sorry should have commented earlier.

THere is somewhat of a hole on the "Intel Graphics" theory as I have 2 machines with Intel graphics and only one of them has the problem.

I have:

- one machine with an i7 that uses the i915 driver, this machine has no issues.
- one machine with 945 GME also uses the i915 driver, this machine has no issues.
- one machine with "Pineview" also uses the i915 driver, this machine is "broken".

I cannot make the machine available online for debugging, sorry. But if there are packages that I need to install for debug output let me know and I can do that.

I'll need 32 bit packages.

@Robert Ancell @Guido will one of you perhaps be at FOSDEM? If so, I could probably bring a device where the problem occurs.

(In reply to comment #35)
> @Robert Ancell @Guido will one of you perhaps be at FOSDEM? If so, I could
> probably bring a device where the problem occurs.

I'm afraid I won't be attending. And unfortunately I'm currently out of ideas on how to debug this further so I hope Robert can come up with something.

Ok, could you please provide some packages where debugging has been enabled, so I could give them a try?

(In reply to comment #37)
> Ok, could you please provide some packages where debugging has been enabled, so
> I could give them a try?

see comment #16;

(In reply to comment #16)
> If the log doesn't give more information we might need to try a LightDM branch
> with some extra debugging added - would either of you be able to build from
> source / is there an easy way to make a package for testing Guido?

I will create packages as soon as such a branch is set up.

(In reply to comment #35)
> @Robert Ancell @Guido will one of you perhaps be at FOSDEM? If so, I could
> probably bring a device where the problem occurs.

I will not be at FOSDEM

Robert

It seems to be not related to the greeter that is used. I have now tried lightdm-kde-greeter with the same result.

Yeah, of course. In fact not only greeters but no X client at all can connect to the X server because of some yet unknown problem with the xauthority files/data, see comment #16.

This affects me too, on MSI Wind U100 (Intel Atom + GMA950). Switching to xdm helped.

I'm seeing this same issue running OpenSUSE 13.1 inside of VirtualBox (4.3.6 r91406 on Mac OS X 10.6.8) with lightdm and xfce. This uses vboxvideo rather than the intel video driver.

The first time the virtual machine boots after the install process lightdm starts fine. At each reboot after that, lightdm fails.

x-0.log states the X Server terminates after loading GLX.

x-0-greeter.log states that lightdm-gtk-greeter could not open the X display

Once I flip to a terminal (cntrl-alt-f5) I can start the X server or lightdm from the command line and everything works fine.

Using lxdm rather than lightdm works fine.

@RobertAncell is there any chance to get some debug information to the packages, so we can work on further on this issue?

I think this might be caused by the X authority not be written before the X server starts, this causes the X server to use an older authority. By the time the greeter starts the correct X authority is used and they don't match.

Could you try the branch [1] (lightdm 1.9) or [2] (lightdm 1.8) or just apply the one line change [3]?

[1] lp:~robert-ancell/lightdm/sync-x-authority
[2] lp:~robert-ancell/lightdm/sync-x-authority-1.8
[3] http://bazaar.launchpad.net/~robert-ancell/lightdm/sync-x-authority/revision/1921

Thanks Robert. I've created a package with the above patch in home:gberh:branches:X11:Utilities/lightdm, could those affected by this bug please (thoroughly) test it and report back here?

(In reply to comment #46)
> Thanks Robert. I've created a package with the above patch in
> home:gberh:branches:X11:Utilities/lightdm, could those affected by this bug
> please (thoroughly) test it and report back here?

Bingo.

Thanks Guido and Robert (not myself obviously ;) ) for working on this and finding and fixing the problem. Just tested the new packages and after 5 reboots with lightdm consistently starting I am happy with the fix.

This is on a system76 netbook

This is an autogenerated message for OBS integration:
This bug (846832) was mentioned in
https://build.opensuse.org/request/show/225785 Factory / lightdm

Since this is a quite tricky bug I'd appreciate it if some more people would test it before I issue a maintenance update. The fix is now included in the X11:Utilities/lightdm package.

Works for me, too. Although I did not find lightdm-lang in your build, so I removed it before upgrading.

Works for me - Thinkpad R60e
Thanks.

OK, thanks. A maintenance update is underway.

Works for me - tested a few warm reboots and cold boots.

running OpenSUSE 13.1 inside of VirtualBox (4.3.6
r91406 on Mac OS X 10.6.8) with lightdm and xfce

This is an autogenerated message for OBS integration:
This bug (846832) was mentioned in
https://build.opensuse.org/request/show/226008 13.1+12.3 / lightdm

This affect me too. Using 13.1 with ATI card on lastest updates. I don't remember it happen before I fully upgrade the system. I don't understand how to fix it.

Thanks all for reporting and fixing.
@Hector, the update isn't released yet, but you can use the package from http://download.opensuse.org/repositories/openSUSE:/Maintenance:/2658/openSUSE_13.1_Update as soon as it's build and published.

Works for me. OpenSUSE 13.1 on a Laptop Macbook Air 13"

Thank you.

Update released for openSUSE 12.3 and 13.1. Resolved fixed.

openSUSE-RU-2014:0426-1: An update that has one recommended fix can now be installed.

Category: recommended (important)
Bug References: 846832
CVE References:
Sources used:
openSUSE 12.3 (src): lightdm-1.4.7-6.7.1

openSUSE-RU-2014:0428-1: An update that has one recommended fix can now be installed.

Category: recommended (important)
Bug References: 846832
CVE References:
Sources used:
openSUSE 13.1 (src): lightdm-1.8.8-11.1