gnome session crashes after login

Bug #15443 reported by Christoph Georgi
26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-session (Ubuntu)
Invalid
Medium
Ubuntu Desktop Bugs

Bug Description

Straight after login in via the gdm the gnome (session) crashes: the spash
screen does not appear; only the backgound (brown) and the mouse pointer can be
seen (without context menu); the "ubuntu sound" does not play. Logs? Couln't
find anything (messages, dmesg, gdm logs)

I had this problem before in the preview releases after some updates, but could
never figure out what package causes this fault.
Now, in Hoary stable, the last thing I did before this bug occured was to add a
custom panel and delete the default Bottom Panel (reasoning in Bug 15442).

I have a second hard drive with Hoary stable, too. Both installations use the
same /home partition. Booting into the second Hoary (I didn't change the panels
there), I couldn't access my desktop either; same problem.
Therefore, I thought that the problem must lie within the user settings in
/home. So I reinstalled (from scratch) Hoary on my second harddrive and was then
able to access my desktop.
Booting into the first partition, the problem persisted. This leads me to the
conclusion that the fault lies not within the settings in /home. But why then
couldn't I access the Desktop in Hoary on the second hard drive?

Reinstalling the meta package ubuntu-desktop did not resolv the issue.

thanks
.christoph

Revision history for this message
Sebastien Bacher (seb128) wrote :

have you looked on ~/.xsession-errors ? does gnome-session crash ? what is the
reply of a "ping 127.0.0.1" ?

Revision history for this message
Christoph Georgi (christoph-georgi) wrote :

After reinstalling Hoary everything was fine. Today the problem occured again
and thank's to you hint, I think I found the problem: The local interface was
not up. After '$sudo ifup lo' everything worked smooth.

Concerning lo: I booted the notebook with a ppp modem attached to it. the ppp
modules get loaded during boot, hence the modem connects during boot. maybe ppp0
prevents lo from being brought up?! (But that seems to be an issue for another
bug).

I'm not too sure whether that was the actual problem and I wont be able to test
the stuff before friday. After testing, I'll let you know more.

thanks
.christoph

Revision history for this message
Christoph Georgi (christoph-georgi) wrote :

I just tested the issue on a testing box: Removed the bottom panel and added a
custom one. No problems after reboot. So it appears that the fault was that the
loopback interface not up, which leaves the question, why I don't have lo when I
use ppp? (I'll open another bug for that if none yet exists).

thanks
.christoph

Revision history for this message
Christoph Georgi (christoph-georgi) wrote :

Sorry for posting some wrong information: the problem was *not* lo being not up,
but ppp being up *and* lo being not up:

When booting my machine without a network cable attached to it, I ctrl+c when
the network interfaces are being configured by init.d. This leaves me with an
unconfigured eth0 and *no* loopback interface. Gnome is running fine!

When booting my machine without a network cable, but a pppoe modem cattached to
it, I do also ctrl+c when the network interfaces a being configured by init.d.
As the modem is connected, before looging into gdm, I have my eth0 interface up
(unconfigured) and a ppp0 interface (configured). I can access the internet via
virtual console. lo is, again, not present! Loging into gdm this time results in
gnome crashing.

After bringing lo manually up, I can log into gnome without any problems again.

So, lo does not seem to be needed for gnome as long as ppp is not up.. That
seems to be the bug?!

regards
.christoph

Revision history for this message
Matt Zimmerman (mdz) wrote :

Please attach a copy of /etc/network/interfaces

Revision history for this message
Malte (malte-m) wrote :

> So, lo does not seem to be needed for gnome as long as ppp is not up.. That
> seems to be the bug?!

I can confirm this behavior - and I'm glad to finally read that I'm not the only
one struggling with this little bug. At least I know now how to solve the issue,
namely by turning lo up, which makes life for me much easier.

Revision history for this message
Hrvoje Marjanovic (hanuman-das) wrote :

(In reply to comment #6)
> > So, lo does not seem to be needed for gnome as long as ppp is not up.. That
> > seems to be the bug?!
>
> I can confirm this behavior - and I'm glad to finally read that I'm not the only
> one struggling with this little bug. At least I know now how to solve the issue,
> namely by turning lo up, which makes life for me much easier.

I have same experience, as soon as I start ppp, I can not log to gnome anymore.

It seems that problem is in the /etc/network/interfaces. This file looked like this:

# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.

iface lo inet loopback

iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth0

-----------------------------------------------
so I just added "auto lo" at the end and everything seems to work since then.

Revision history for this message
Malte (malte-m) wrote :

Since the solution is known now, doesn't anybody feel like fixing this?

Revision history for this message
Matt Zimmerman (mdz) wrote :

(In reply to comment #8)
> Since the solution is known now, doesn't anybody feel like fixing this?

I think you misunderstand the situation; there is no solution described in this
bug report. The root cause of the problem has not been found yet; it is not
clear why the "auto lo" line was missing from /etc/network/interfaces (it is
placed there in a default installation of Ubuntu).

Perhaps it was changed by network-admin?

Revision history for this message
Ruben Vermeersch (ruben) wrote :

I'm experiencing quite similar things:

After login, I get an "app crashed" dialog, if I click restart app, my desktop
starts to boot.

From .xsession-errors:

    _IceTransTransNoListen: unable to find transport: tcp
    _IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
    _IceTransmkdir: ERROR: Cannot create /dev/X
    _IceTransPTSOpenServer: mkdir(/dev/X) failed, errno = 13
    _IceTransOpen: transport open failed for pts/tokyo:
    _IceTransMakeAllCOTSServerListeners: failed to open listener for pts
    _IceTransISCOpenServer: Protocol is not supported by a ISC connection
    _IceTransOpen: transport open failed for isc/tokyo:
    _IceTransMakeAllCOTSServerListeners: failed to open listener for isc
    _IceTransSCOOpenServer: Protocol is not supported by a SCO connection
    _IceTransOpen: transport open failed for sco/tokyo:
    _IceTransMakeAllCOTSServerListeners: failed to open listener for sco
    SESSION_MANAGER=unix/tokyo:/tmp/.ICE-unix/6213

    ** (gnome-session:6213): WARNING **: Host name lookup failure on localhost.
    Gnome-Message: gnome_execute_async_with_env_fds: returning -1

However, my /etc/network/interfaces looks like this:

    iface lo inet loopback
    auto lo

    iface eth1 inet dhcp
    wireless-essid osaka
    wireless-key s:XXXXXXXXXXX
    auto eth1

And my /etc/hosts tops with the following line:

    127.0.0.1 localhost.localdomain localhost tokyo

I also verified if lo was up by putting an ifconfig call in the GDM startup
script, this was the case. This PC was a well-running hoary, now upgraded to
breezy, this being the most obvious degradation.

Revision history for this message
Marcelo Cohen (marcelo-cohen) wrote :
Download full text (4.1 KiB)

(In reply to comment #10)
> I'm experiencing quite similar things:

I second that, but in my case, nothing seems to be running, apart from the
X server itself. I get only the background and mouse pointer, but the
keyboard is completely locked - can't even switch to virtual terminals
or exit the server.

My .xsession-errors is quite similar:

/etc/gdm/PreSession/Default: Registering your session with wtmp and utmp
/etc/gdm/PreSession/Default: running: /usr/bin/X11/sessreg -a -w /var/log/wtmp
-u /var/run/utmp -x "/var/lib/gdm/:0.Xservers" -h "" -l ":0" "goo"
/etc/gdm/Xsession: Beginning session setup...
_IceTransTransNoListen: unable to find transport: tcp
_IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
_IceTransmkdir: ERROR: Cannot create /dev/X
_IceTransPTSOpenServer: mkdir(/dev/X) failed, errno = 13
_IceTransOpen: transport open failed for pts/qigong:
_IceTransMakeAllCOTSServerListeners: failed to open listener for pts
_IceTransISCOpenServer: Protocol is not supported by a ISC connection
_IceTransOpen: transport open failed for isc/qigong:
_IceTransMakeAllCOTSServerListeners: failed to open listener for isc
_IceTransSCOOpenServer: Protocol is not supported by a SCO connection
_IceTransOpen: transport open failed for sco/qigong:
_IceTransMakeAllCOTSServerListeners: failed to open listener for sco
SESSION_MANAGER=unix/qigong:/tmp/.ICE-unix/7300
Xsession: X session started for goo at Sat Sep 10 16:39:33 BST 2005

This is happening on a clean Breezy installation and a new user as well (although
I'm using my /home partition from Hoary).

After dist-upgrading, Gnome *seems* to start and this shows up below:

** (gnome-session:7147): WARNING **: Host name lookup failure on localhost.
Gnome-Message: gnome_execute_async_with_env_fds: returning -1
manager.c/557: setting[0]: bool: autobrowse = 1
manager.c/557: setting[1]: bool: autoburn = 0
manager.c/552: setting[2]: string: autoburn_audio_cd_command = serpentine
manager.c/552: setting[3]: string: autoburn_photo_cd_command = nautilus
--no-desktop burn:
manager.c/552: setting[4]: string: autoburn_data_cd_command = nautilus
--no-desktop burn:
manager.c/557: setting[5]: bool: autoipod = 0
manager.c/552: setting[6]: string: autoipod_command =
manager.c/557: setting[7]: bool: automount_drives = 1
manager.c/557: setting[8]: bool: automount_media = 1
manager.c/557: setting[9]: bool: autophoto = 1
manager.c/552: setting[10]: string: autophoto_command =
gnome-volume-manager-gthumb %h
manager.c/557: setting[11]: bool: autoplay_cda = 1
manager.c/552: setting[12]: string: autoplay_cda_command = totem %d
manager.c/557: setting[13]: bool: autoplay_dvd = 1
manager.c/552: setting[14]: string: autoplay_dvd_command = totem %d
manager.c/557: setting[15]: bool: autoplay_vcd = 1
manager.c/552: setting[16]: string: autoplay_vcd_command = totem %d
manager.c/557: setting[17]: bool: autoprinter = 1
manager.c/552: setting[18]: string: autoprinter_command = gnome-printer-add hal://%h
manager.c/557: setting[19]: bool: autorun = 0
manager.c/552: setting[20]: string: autorun_path = .autorun:autorun:autorun.sh
manager.c/552: setting[21]: string: eject_command = /usr/bin/eject
Gnome-Message: gnome_execute_async...

Read more...

Revision history for this message
Sebastien Bacher (seb128) wrote :

(In reply to comment #10)

> ** (gnome-session:6213): WARNING **: Host name lookup failure on localhost.
> Gnome-Message: gnome_execute_async_with_env_fds: returning -1

GNOME tries to start something which is not installed on your box. Do you have
ubuntu-desktop installed?

Revision history for this message
Sebastien Bacher (seb128) wrote :

(In reply to comment #10)
> I'm experiencing quite similar things:
>
> After login, I get an "app crashed" dialog, if I click restart app, my desktop
> starts to boot.

What application crashes? Can you get a backtrace with the bug-buddy dialog you
get with the dialog to send a bug upstream?

Revision history for this message
Marcelo Cohen (marcelo-cohen) wrote :

(In reply to comment #11)
> (In reply to comment #10)
> > I'm experiencing quite similar things:
>
> I second that, but in my case, nothing seems to be running, apart from the
> X server itself. I get only the background and mouse pointer, but the
> keyboard is completely locked - can't even switch to virtual terminals
> or exit the server.

UPDATE: after changing the X driver from nv to nvidia, it works fine. Seems
to be something related to nv or was it just coincidence ?

Revision history for this message
draknet (n638jl66) wrote :

Glad to see that it is not just me who has this problem.

I can confirm the following behavior:

1. Without a network cable plugged in the login from completing the gdm login
until full desktop is about 25s. Logout also is just a couple of seconds.
2. With network cable plugged and lo _not_ configured the login time is around 5
minutes! Logout also some minutes.
3. With network cable plugged and lo configured the login time is again 25s.
Logon also a couple of seconds.

I see that sometimes when I choose profiles in the Gnome network configuration
dialog "auto lo" disappears from /etc/network/interfaces. So I suspect the
network configuration dialog to be the problem.

Revision history for this message
sonium (sonium) wrote :

I have similar problems on fresh installed 5.10

here are some files that might help:

/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
mapping hotplug
 script grep
 map wlan0

# The primary network interface
iface wlan0 inet dhcp
 # wireless-* options are implemented by the wireless-tools package
 wireless-mode managed
 wireless-essid ******

and /home/sonium/.xserver-errors

/etc/gdm/PreSession/Default: Registering your session with wtmp and utmp
/etc/gdm/PreSession/Default: running: /usr/bin/X11/sessreg -a -w /var/log/wtmp
-u /var/run/utmp -x "/var/lib/gdm/:0.Xservers" -h "" -l ":0" "sonium"
/etc/gdm/Xsession: Beginning session setup...
_IceTransTransNoListen: unable to find transport: tcp
_IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
_IceTransmkdir: ERROR: Cannot create /dev/X
_IceTransPTSOpenServer: mkdir(/dev/X) failed, errno = 13
_IceTransOpen: transport open failed for pts/raumstation:
_IceTransMakeAllCOTSServerListeners: failed to open listener for pts
_IceTransISCOpenServer: Protocol is not supported by a ISC connection
_IceTransOpen: transport open failed for isc/raumstation:
_IceTransMakeAllCOTSServerListeners: failed to open listener for isc
_IceTransSCOOpenServer: Protocol is not supported by a SCO connection
_IceTransOpen: transport open failed for sco/raumstation:
_IceTransMakeAllCOTSServerListeners: failed to open listener for sco
SESSION_MANAGER=unix/raumstation:/tmp/.ICE-unix/9359

seems like there is no definitly solution now, yet?

Revision history for this message
sonium (sonium) wrote :

I also tested Dapper Drake and have still the same problem.

Revision history for this message
Egidijus (egidijus) wrote :

I am nor running gdm because don't have Gnome but have Xfce4 with wdm.

But when running startxfce4 or startx from console
or from wdm menu Xfce (i think it run the same startxfce4)
I get these errors in .Xsession-errors in home directory:

_IceTransTransNoListen: unable to find transport: tcp
_IceTransmkdir: ERROR: euid != 0,directory /dev/X will not be created.
_IceTransmkdir: ERROR: Cannot create /dev/X
_IceTransPTSOpenServer: mkdir(/dev/X) failed, errno = 13
_IceTransOpen: transport open failed for pts/ubuntu:
_IceTransMakeAllCOTSServerListeners: failed to open listener for pts
_IceTransISCOpenServer: Protocol is not supported by a ISC connection
_IceTransOpen: transport open failed for isc/ubuntu:
_IceTransMakeAllCOTSServerListeners: failed to open listener for isc
_IceTransSCOOpenServer: Protocol is not supported by a SCO connection
_IceTransOpen: transport open failed for sco/ubuntu:
_IceTransMakeAllCOTSServerListeners: failed to open listener for sco

But when i start xfwm4 from wdm menu i have no these errors
But then i have no xfce4-panel xfdesktop xftaskbar4 running.

So any coments on this errors?

Revision history for this message
Daniel Holbach (dholbach) wrote :

Daniel, do you have any ideas on the _Ice* messages?

Revision history for this message
Phil Bull (philbull) wrote :

Do you still have this issue with the latest Dapper packages?

Revision history for this message
higuita (higuita) wrote :

is bug 40176 a dupe of this?

https://launchpad.net/distros/ubuntu/+bug/40176/+index

seens too, and if so, its related with esd

Revision history for this message
Lucas Nussbaum (lucas) wrote : Re: [Bug 15443] Re: gnome session crashes after login

On 25/04/06 at 20:48 -0000, higuita wrote:
> is bug 40176 a dupe of this?
>
> https://launchpad.net/distros/ubuntu/+bug/40176/+index
>
> seens too, and if so, its related with esd

It's not really the same problem. But esd really desserves more
attention ...
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

Revision history for this message
Patrick Ohearn (patoh) wrote :

Iam having same issue with edgy, if i reboot and login into gnome its all good. But when i restart X and try to login gnome-session crashes with a return code of 1. I have to reboot to get it to startup again unless i call from a console, it crashes if ran via the run dialog (Alt+F2).

Revision history for this message
Sebastien Bacher (seb128) wrote :

when that happens on edgy, do you have still some process of that user running? Could you get a backtrace of the crash or the log of what happens before exiting if it doesn't crash?

Revision history for this message
Sebastian Breier (tomcat42) wrote :

@Patrick, @Sebastien:
I think Patrick is talking about bug #59217 (bug #60477 is a duplicate, has good info). I have the same issue and it doesn't look like the reporter's problem.

Patrick, please check these bugs to see if that's your problem.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Christoph, do you still have that bug?

Revision history for this message
Sebastien Bacher (seb128) wrote :

No reply, bug closed. Feel free to reopen if that's still a problem with edgy or feisty

Changed in gnome-session:
assignee: seb128 → desktop-bugs
Changed in gnome-session:
status: Needs Info → Rejected
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.