gdm spawns a new X server when told to restart the system

[Oliver Grawert]

Binary package hint: gdm

if you shut down from the gdm menu, gdm and X end.
then gdm respawns with the default gnome theme, sits there for a second and only then starts the actual shutdown process.
thats on a system installed from edubuntu gutsy tribe3 candidate

[Sebastien Bacher (seb128)]

Do you still have the issue? I don't get the issue. Maybe it's due to the video card or xorg context switch?

[Thom Pischke (thom-pischke)]

I see it still if I shutdown from the ubuntu login screen.

see also issue128577

[Matt Zimmerman (mdz)]

I see this as well, on my desktop. My session ends, but then the X server is respawned (presumably by gdm) during shutdown, displaying the default GNOME theme instead of the Ubuntu one. It stays there until sendsigs runs and kills all remaining processes.

[Bryce Harrington (bryce)]

I've tried several permutations but like seb, I also am unable to reproduce the issue on an nv system updated to latest Gutsy. Can those seeing the issue, report details about their hardware?

Also, it would be helpful to have an exact set of steps for reproducing the issue - E.g., did you boot and log all the way into X, then log out, and shutdown from gdm, or did you boot and then immediately shutdown from gdm without going into X?

[Matt Zimmerman (mdz)]

I can reproduce the problem on a clean boot, restarting from the greeter without logging in. I see identical symptoms, with complete reproduceability, on my desktop (nvidia) and my laptop (ati). I do not think it is hardware-related.

I set gdm's reboot command to /bin/true to be able to examine the situation a bit. When it gets into this state, the original gdm parent process is still running, though /var/run/gdm.pit and gdm_socket are both gone.

I've attached gdm's log output from daemon.log.

[Sebastien Bacher (seb128)]

Do you have the issue every time? I had gdm restarting on shutdown and I think that's because the package was upgraded during the session. The gdm restart on package upgrade is delayed to not closed the session immediatly. Do you think it happened for you after an upgrade?

[Matt Zimmerman (mdz)]

On Fri, Aug 31, 2007 at 12:40:11PM -0000, Sebastien Bacher wrote:
> Do you have the issue every time? I had gdm restarting on shutdown and I
> think that's because the package was upgraded during the session. The
> gdm restart on package upgrade is delayed to not closed the session
> immediatly. Do you think it happened for you after an upgrade?

I tested this under controlled circumstances, with repeated reboots without
even logging in, so no, it was definitely not upgraded during my test.

--
 - mdz

[Matt Zimmerman (mdz)]

Were the logs helpful at all? What other information can I collect which
would help to diagnose the problem?

--
 - mdz

[Oliver Grawert (ogra)]

no upgrades here when it showed

[Matt Zimmerman (mdz)]

Please see bug 123043, where I experienced something similar, but saw the default GNOME greeter instead of the standard Ubuntu one. Perhaps there's a clue here as to what is happening?

[Thom Pischke (thom-pischke)]

Ugh. Getting this problem again after upgrading a completely different computer to gutsy beta. Worse, the desktop theme doesn't load properly and I'm stuck with something reminiscent of Windows 95 theming.

Dell Inspiron 6000

[Thom Pischke (thom-pischke)]

Also worth mentioning, logging out and trying to log back in as another user will often hang the system irrecoverably. I suspect it's related.

Time to bump the priority on this? Serious problem with this so far on 2 out of 3 laptops, all with completely different hardware.

[Thom Pischke (thom-pischke)]

there appears to be a possible correlation between this and bug 148291

[Robin Sheat (eythian)]

I'm having X restart on logout (not shutdown), which apparently is related to this, and means twinview with nvidia has issues.

[Matt Zimmerman (mdz)]

On Fri, Oct 05, 2007 at 09:36:36AM -0000, Eythian wrote:
> I'm having X restart on logout (not shutdown), which apparently is
> related to this, and means twinview with nvidia has issues.

Sounds like a completely unrelated issue.

--
 - mdz

[Thom Pischke (thom-pischke)]

On further investigation, bug 148291 also seems unrelated to this.

[Robin Sheat (eythian)]

It's bug 149330 that I'm having problems with (that was marked a dupe of this). If it's not related, please un-dupe it, I don't think I'm able to do that.

[Gert Kulyk (gkulyk)]

It seems like https://bugzilla.novell.com/attachment.cgi?id=174000 for Novell Bug 326281 contains a patch for this. Seems like a workaround.

[Mark Crutch (markc-qsiuk)]

In case it helps anyone to reproduce this issue, I've run into this problem using Gutsy in a virtual machine running on VMWare Server. The "Screens and Graphics" app lists the driver as "vmware - VMWare virtual video cards". The machine was formerly running Feisty and has been upgraded to Gutsy.

[Psychcf (psychcf)]

We need to step this bug's priority up big time. With gutsy a few days away from release we'll have many people upgrading from feisty to gutsy, and they will experience this problem as well.

I had this problem after upgrading from feisty to gutsy yesterday. I have my box set to automatically log me in, so it goes through the login process, and then dies when the system kills the remaining processes. I'm wondering if this only has to do with the people that upgraded from feisty though.

[Psychcf (psychcf)]

Oddly enough I just had a package update for GDM today, the issue seemed to correct itself. I'm going to wipe my system and start from scratch though.

[NoWhereMan (e.vacchi) (uncommonnonsense)]

the bug is still there feisty>gutsy update

[Bryce Harrington (bryce)]

I've packaged the aforementioned patch here:

 http://people.ubuntu.com/~bryce/Testing/gdm/

Basically it just adds a couple sleep()'s, which does seem a tad hacky, but seems to be a fairly safe way to workaround the problem. The potential downside could be if it lengthens the restart process noticeably.

Would someone mind testing this and confirming it addresses the problem?

[Bryce Harrington (bryce)]

Has anyone had a chance to test this? Is the problem even still an issue? It's gotten to be too late to push this for Hardy but if it still occurs I'll queue it to go in for Intrepid.

If no one responds with test results within a couple months, I'll assume the problem has resolved itself and we can close this bug as out of date.

[Matt Zimmerman (mdz)]

I am traveling and don't have access to the systems in question. I will check them next week when I update them (which will require restarts anyway).

[Sharon Talbot (sharon-talbot)]

We still have this problem. It is especially apparent for us because we have 25 machines running folding that students use and sometimes reboot into Windows. Folding slows the logout process significantly, and during this time gdm comes back up and you can log in, however, the machine is still in the process of logging out and when it finishes roughly 90 seconds later it reboots, regardless of whether someone has logged in or not.

It seems to me the problem is caused by killing gdm on logout instead of stopping it.

[Matt Zimmerman (mdz)]

I just saw this again on a hardy->intrepid upgrade

[Sebastien Bacher (seb128)]

the issue is deprecated in the new gdm shipped since karmic, closing the bug