Bug 887507

An abrt-report and/or backtrace would help.

Created attachment 664322 [details]
/varr/log/lightdm/lightdm.log

I ran lightdm from a terminal as:
  lightdm --log-dir=/var/log/lightdm -d --test-mode

^c broke in.

This was run in a qemu/kvm/libvirt/virt-manager with a virtual console.

Also .. in runlevel 3

Created attachment 664323 [details]
/var/log/lightdm/x-0.log

I have the problem isolated down the the package which causes lightdm to get into the fail-loop: xorg-x11-drv-qxl

In the last couple days I installed F18 into a qemu-kvm/libvirt virtual system and used virt-manager also.  The install did not include anything form updates-testing and, to my surprise, lightdm worked just fine.  But, after I updated to updates-testing, I had the problem again.

THrough trail and error and increamentally updates a few packages at a time, I isolated the cause.  With the "qxl" package installed, I had the problem.  Without the update to 0.1.0-1, the problem was there.

I am not sure if this is a lightdm problem or a "qxl" problem but "qxl" is suspicious.

Haven't seen this recently with F18 but it is happening for F19 Rawhide.

(I just tested F18 XFCE Live in virt-manager which default to qxl
and it works fine.)

Any particular files in /var/log/lightdm/ you want to see?

(In reply to comment #5)
> it is happening for F19 Rawhide.

Switching from qxl to a different virt graphics chip seems to fix it.

Do we have any signs that lightdm actually *crashes*? 
"Server terminated successfully (0). Closing log file." doesn't sound like a crash to me, I assume it's more like the xserver crashed.

Does startx work with the qxl driver installed?

> Does startx work with the qxl driver installed?

Yes, and gdm too.

Created attachment 689708 [details]
debug.output

This is the debug output I see on stderr when running "lightdm -d" in current rawhide.

I interrupted it after several X loops by holding down Ctrl-c.

Based on the log submitted, its the greeter exiting unexpectedly (crash?), reassigning...

Sorry, this is NOT fix in Fedora 18 (and is likely not fixed in rawhide either).  I just ran a test and it is still there.  I can provide any needed info.

My test was:
1. Fedora 18 on host with qemu-kvm/libvirt virtualization

2. Fedora 18 on virtual system.  After:
      systemctl  --force  enable  lightdm.service
and rebooting, I got loop and had to force-shutdown.

Both host and virtual had been updated to current Fedora+updates

see comment #1 (if crash is occurring, a backtrace is likely required to find what's going wrong where)

I have no idea how to get a backtrace in this situation.  However, in attempt to move things along I ran an strace:
    strace -f -o lightdm.st /usr/sbin/lightdm -d

There are two files that may be of interest: /var/log/lightdm/lightdm.log and the output of strace.  The strace file is a bit large (about 4MB) and I am reluctant to attach it here.

I am going to try and edit the two files so that just a complete cycle is captured which should cut down on the size (it looped for three or four times).  I gzipped the strace file and that reduced 4MB  to around 512KB.

So, how do you want this info.  Do you want it.

Created attachment 690574 [details]
lightdm.log from latest test (2 cycles)

Created attachment 690599 [details]
xz compressed strace output

editing for 2 cycles brought it down to 2.7MB.

with gzip: 342KB
with bzip2: 244KB
with xz: 153KB  .... I am impressed

So xz it is

Actually I realised I only see the light-gtk crash on F19 rawhide guest when using qxl - sorry if I hijacked your report - anyway I can't reproduce on F18 (neither guest nor host).

And I only see it with lightdm-gtk and qxl which I only have as a virtual device.  Using lightdm-kde, lxdm, etc. seem to work OK.  I need to track down what produces a 239 return code.

Ok reassigning to the qxl driver then.

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

*** This bug has been marked as a duplicate of bug 915986 ***