Bug 138842

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
/usr/lib/libORBit-2.so.0
#7  0x00b29b88 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#8  0x00b29da9 in ORBit_small_invoke_stub_n () from
/usr/lib/libORBit-2.so.0
#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
/usr/lib/libgobject-2.0.so.0
#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

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
harddisk.

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.

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.

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
192.168.0.9:/home       /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   
pamconsole,fscontext=system_u:object_r:removable_t,ro,exec,noauto,managed
0 0
#/dev/fd0                /media/floppy           auto   
pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0

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.

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
working...

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.

I see the same problem after upgrading.

Besides Nautilus, eggcups fails to load, and also does
gnome-volume-manager.

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

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..

When this happens, can you try to kill gnome-vfs-daemon and see if
that affects it?

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

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.

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.

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.

Adrianna

Has anyone here tried running 'bonobo-slay'?  This seems to have great impact on
my problems.

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.

Created attachment 128429 [details]
Hang backtrace from pstack

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!

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.