Bug 138842 - Nautilus hangs upon login (No desktop)
Summary: Nautilus hangs upon login (No desktop)
Alias: None
Product: Fedora
Classification: Fedora
Component: nautilus
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
: 139138 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-11 15:32 UTC by Paul Stadler
Modified: 2009-10-12 19:25 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2006-10-30 22:17:06 UTC

Attachments (Terms of Use)
Hang backtrace from pstack (2.37 KB, text/plain)
2006-05-01 00:12 UTC, Stephen Tweedie
no flags Details

Description Paul Stadler 2004-11-11 15:32:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Login to using the graphical login.
2. Wait to see the desktop.


Actual Results:  Nautilus does not startup and/or display the desktop.

Expected Results:  Nautilus should display the desktop and associated
icons, etc...

Additional info:

After logging in from the graphical login screen, my desktop wasn't
there. My 'ps aux' shows this:

username  3708  0.0  3.1 34660 7792 ?       Ssl   10:00   0:00
nautilus --no-default-window --sm-client-id default3
username  3932  0.0  3.1 34660 7788 ?       Ssl   10:06   0:00
nautilus --no-default-window --sm-client-id default3
username  4102  2.0  3.1 34796 7788 ?       Ssl   10:00   0:00
nautilus --no-default-window --sm-client-id default3

As an aside, I did two things last night before rebooting that may be
  - Installed the development system using yum.
  - Did a system-wide upgrade using yum.

Next, after killing the processes above, I tried to attach GDB to the
process. First I logged out, logged back in... and checked for the new
PID. Then I attached using "gdb program 4481". This spewed a bit of
debug info onto the data about trying to (and failing to) load
symbols.  Then the program was interrupted by a SIGINT. Here's what
GDB said then:

Program received signal SIGINT, Interrupt.
0x003617a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

Okay... so then I checked what version I have of ld-linux.so.2... and
I'm running whatever version is from glibc-2.3.3-74... according to
RPM. Now... that is one of the files that was installed last night for
me so I might be seeing a correlation here.

Also of note:
I tried this process from two accounts... one that's highly customized
and the other which is the root account -- stock.

I tried to run nautilus just standalone from an XTerm as well. This
related in the same behavior -- locking up -- and breaking at the same
point in ld-linux.so.

I'm running Gnome not KDE...


Comment 1 Paul Stadler 2004-11-11 18:39:07 UTC
Here's some more info from GDB...

(gdb) backtrace
#0  0x003617a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x004f7ac6 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0x00b42404 in link_wait () from /usr/lib/libORBit-2.so.0
#3  0x00b43a8b in link_connection_try_reconnect ()
   from /usr/lib/libORBit-2.so.0
#4  0x00b22e74 in giop_connection_try_reconnect ()
   from /usr/lib/libORBit-2.so.0
#5  0x00b2be4e in ORBit_objref_get_proxy () from /usr/lib/libORBit-2.so.0
#6  0x00b2c0a5 in ORBit_object_get_connection () from
#7  0x00b29b88 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#8  0x00b29da9 in ORBit_small_invoke_stub_n () from
#9  0x00b3c3a7 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#10 0x008d3131 in GNOME_VFS_Daemon_getDrives ()
   from /usr/lib/libgnomevfs-2.so.0
#11 0x00901f7c in gnome_vfs_volume_monitor_client_get_type ()
   from /usr/lib/libgnomevfs-2.so.0
#12 0x00902164 in gnome_vfs_volume_monitor_client_get_type ()
   from /usr/lib/libgnomevfs-2.so.0
#13 0x0082e2cc in g_type_create_instance () from
#14 0x008155a1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#15 0x0081483f in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#16 0x00815459 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0
#17 0x00815578 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#18 0x00902949 in _gnome_vfs_get_volume_monitor_internal ()
   from /usr/lib/libgnomevfs-2.so.0
#19 0x009029a0 in gnome_vfs_get_volume_monitor ()
   from /usr/lib/libgnomevfs-2.so.0
#20 0x08069440 in nautilus_application_get_spatial_window_list ()
#21 0x099e1270 in ?? ()
#22 0x00d427dc in bonobo_object_get_type () from /usr/lib/libbonobo-2.so.0

Comment 2 Gijs Hollestelle 2004-11-18 15:53:24 UTC
I'm having this same problem it appears to be haldaemon related. Doing
a /etc/init.d/haldaemon stop from the console before logging in makes
nautilus start normally.

I have a test setup here with multiple PCs all having the same set of
RPMs installed and nfs mounted /home I only have this problem on one
pc, it could be sata related as this is the only pc that has a SATA

Comment 3 Quereller 2004-11-18 16:58:26 UTC
I had a similar problem, while playing around with gamin.
Don`t know what`s exactly the problem. But logging out, deleting
entries in /tmp and rebooting fixed it for me.

Comment 4 Gijs Hollestelle 2004-11-24 18:53:08 UTC
I tracked this problem down to a problem with /etc/fstab I had the
following in there (to be able to mount two different types of vfat
USB disks on a Redhat 9 system):

/dev/sda                /mnt/usbdrive-sf           vfat   
noauto,owner,umask=0077 0 0
/dev/sda1               /mnt/usbdrive           vfat   
noauto,owner,umask=0077 0 0

This gave no problems on any of my machines except for the ones that
have SATA drives, because there /dev/sda1 is also the / partition. 

I have been able to reproduce the problem on non sata machines as well
by placing the above in /etc/fstab, replacing sda by hda and sda1 by
hdax where x is the number of the / partition. After restarting
haldaemon nautilus also hangs on startup.

Comment 5 Juraj Bednar 2004-11-27 16:34:25 UTC
This looks as the same bug as mine: 140994.

The common thing is that I also have homedirectories mounted via NFS,
but all are the same versions of fedora core 3. Unfortunately,
stopping haldaemon does not help me.

I also have no desktop and can't start filebrowser. This also occured
during the update (up2date). 

My fstab:

Nov 27 17:30:49 no8 kernel: agpgart: Putting AGP V2 device at
0000:01:00.0 into # This file is edited by fstab-sync - see 'man
fstab-sync' for details
/dev/hda2                /                       ext3    defaults    
   1 1
/dev/hda1             /boot                   ext3    defaults        1 2       /home                   nfs    
soft,intr,rsize=8192,wsize=8192,nosuid,tcp      1 2
none                    /dev/pts                devpts  gid=5,mode=620
 0 0
none                    /dev/shm                tmpfs   defaults     
  0 0
none                    /proc                   proc    defaults     
  0 0
none                    /sys                    sysfs   defaults     
  0 0
/dev/hda3                swap                    swap    defaults    
   0 0
#/dev/hdc                /media/cdrom            auto   
0 0
#/dev/fd0                /media/floppy           auto   
pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0

Comment 6 Juraj Bednar 2004-11-27 16:53:25 UTC
Also erasing tmp and rebooting, stopping hal daemon, fiddling with
fstab -- nothing helps. I also tried downgrading to version from fc3
and it did not help either.

Comment 7 Juraj Bednar 2004-11-27 17:19:08 UTC
ok, sorry for spam, but I'm trying to narrow all the possibilities, I
hope my input is useful. I copied user's homedir from NFS mounted
/home to local disk. So now /home and user's homedir is on local
filesystem. I also commented out everything but proc and sysfs from
/etc/fstab, so I believe there's no error or anything it would hate in
fstab either.

I logged in to GNOME, killed all hanging instances of nautilus, ran
strace on nautilus. The end of strace output is this:

futex(0x9312c24, FUTEX_WAKE, 1)         = 1
writev(24, [{"GIOP\1\2\1\0\210\1\0\0", 12},
{"P\364\343\376\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0u\220X\310"..., 392}],
2) = 404
futex(0x92156c0, FUTEX_WAKE, 1)         = 1
writev(24, [{"GIOP\1\2\1\0\220\1\0\0", 12},
{"\320\364\343\376\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0u\220"..., 400}],
2) = 412
futex(0x9232b9c, FUTEX_WAIT, 3, NULL)   = 0
futex(0x9232b78, FUTEX_WAKE, 1)         = 0
futex(0x9232ae4, FUTEX_WAIT, 1, NULL

Of course gdb stack trace is still the same. 

I also created another new user, which got fresh homedirectory on
local disk from /etc/skel and logged in -- everything the same.
Downgrading nautilus also didn't help, so I'm quite out of ideas what
could be causing this now. 

BTW: Hal daemon does not start on my machine. I thought it could be
realted to bug no. 131348, so I tried to run this:

[root@no8 prototyp]# /usr/sbin/hald --daemon=no --verbose=yes
18:16:34.771 [I] hald.c:394: hal 0.4.0
18:16:34.773 [I] hald.c:398: Will not daemonize
Segmentation fault

So I tried to reinstall previous version (the one that came with
fedora core 3, without any updates). This time, everything started

So it may have some connection with hald not running -- anyways, this
is still a bug in nautilus, it should warn it's users, this behaviour
(I hope) is unnaceptable in fedora stable.

Comment 8 Santiago Bosio 2004-11-29 19:38:00 UTC
I see the same problem after upgrading.

Besides Nautilus, eggcups fails to load, and also does

Comment 9 Josh N 2004-12-07 18:28:57 UTC
I have run into the same problem after upgrading from FC2 to FC3 with
yum. I can't right-click, no desktop icons, mozilla and firefox hang
when I try to save an attachment and of course nautilus hangs when I
try to run it from the command line. I tried stopping haldaemon and
cleaning up /tmp to no avail. I also tried removing nautilus with yum
and then re-installing as I had read that post somewhere else, but
that also didn't work. I also tried looking at my preferences with the
gconf-editor but couldn't make heads or tails of how to fix this
specific problem.

#ps info for nautilus
500       3501  0.0  2.1 32856 8348 ?        Ssl  10:09   0:00
nautilus --sm-config-prefix /nautilus-UV68Ak/ --sm-client-id
117f000001000109457309300000023370003 --screen 0

Comment 10 Tobias Bradtke 2004-12-11 22:14:15 UTC
I have the same problem. But i'm running Fedora-Core-3 for some time
with no problem and i did no updates before this error occured..

The last thing i did was using "Imendio Blam": "Filemenu -> export OPLM"
After this i couldn't start any filebrowser and the icons on the
background were gone. I don't think "Imendio Blam" has anything to do
with it. I only wanted to say that i did a simple "save file" and no
yum or any other heavily update things for some days..

Comment 11 Alexander Larsson 2005-01-11 14:40:14 UTC
When this happens, can you try to kill gnome-vfs-daemon and see if
that affects it?

Comment 12 Alexander Larsson 2005-01-11 14:48:42 UTC
*** Bug 139138 has been marked as a duplicate of this bug. ***

Comment 13 Josh N 2005-01-12 03:05:03 UTC
I tried to kill the gnome-vfs-daemon after I booted into gnome with no
desktop (FC3 latest kernel) and nothing happened. I also, tried to
restart the gnome-settings-daemon and nothing happened as well. To add
a little info to the problem, it also turns out that after I am in
this situation if I attempt to logout from the menu, the system
freezes. No console response to any mouse clicks and I had to
ctl-alt-backspace to get back to the login screen. Not sure if that
helps, but figured I would put it in there anyway.

Comment 14 Ron McKown 2005-02-25 14:02:03 UTC
I've just upgraded my office to FC3.  All of the hardware is identical
and I used an image so all the machines have idenitical packages. 
However, two of the six machines have this nautilus hang problem.  The
actual nautilus process cannot even be killed from command line.

I did find something interesting:  As soon as you login, and nautilus
never draws the desktop, click on Main Menu (the red hat) and choose
Network Servers and nautilus immediately draws the desktop.

Comment 15 Adrianna Pinska 2005-04-03 10:39:43 UTC
I had the same symptoms after a full yum upgrade.  In my case, the problem was
an old bonobo rpm which had been installed on my system as a dependency during
the initial install, *together with* the new libbonobo rpm which is supposed to
replace it.

I uninstalled the bonobo rpm, together with the two programs which depended on
it, ran bonobo-slay and logged back in, and it was fine.

It seems that the same symptoms can be caused by a wide range of different
problems.  It would be helpful if nautilus could give more verbose output about
what it's doing.


Comment 16 Joshua Schmidlkofer 2005-04-30 07:19:43 UTC
Has anyone here tried running 'bonobo-slay'?  This seems to have great impact on
my problems.

Comment 17 Stephen Tweedie 2006-05-01 00:10:50 UTC
Just reproduced this on RHEL-4, for what it's worth.  The problem was the same
as in comment #4: I had moved a system from ATA to SATA drives, and had an old
/etc/fstab containing

/dev/sda               /mnt/floppy             auto    user,noauto     0 0

which was causing this exact nautilus hang, with an almost identical backtrace
to comment #1.  It was not due to per-user data: even newly-created test users
had the same symptoms.  Commenting out that single line in /etc/fstab resulted
in nautilus starting fine.

Exact pstack backtrace to be attached.

Comment 18 Stephen Tweedie 2006-05-01 00:12:29 UTC
Created attachment 128429 [details]
Hang backtrace from pstack

Comment 19 Matthew Miller 2006-07-10 21:25:39 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Comment 20 John Thacker 2006-10-30 22:17:06 UTC
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

Note You need to log in before you can comment on or make changes to this bug.