Nautilus UI blocks while a disk spins up from standby when nautilus-open-terminal is installed

[Alexander Jones]

When, say, a HDD spins down to sleep and you try to access it via Nautilus, Nautilus will block until the disk spins up and responds.

This does not affect a fresh installation. Only after installing nautilus-open-terminal does it happen.

ProblemType: Bug
Architecture: amd64
Date: Sun Apr 13 23:35:30 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/nautilus
NonfreeKernelModules: nvidia ath_hal
Package: nautilus 1:2.22.2-0ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
Uname: Linux 2.6.24-15-generic x86_64

[Sebastien Bacher (seb128)]

Thank you for your bug report. Nautilus is usually using async calls and I dont notice this issue, could be due to some third party code installed (there was such issues due to file-roller and nautilus-cd-burner), could you get a nautilus stacktrace while it's hanging?

[Alexander Jones (alex-weej)]

This is really hard, I have GDB attached to Nautilus but it's whinging
every time I open a folder about:

Spurious thread death event.

Which I have to continue from...

[Alexander Jones (alex-weej)]

(gdb) c
Continuing.
Spurious thread death event.
(gdb) c
Continuing.
[New Thread 0x43695950 (LWP 730)]
Cannot get thread event message: debugger service failed
(gdb) c
Continuing.
[New Thread 0x41670950 (LWP 731)]
Cannot get thread event message: debugger service failed
(gdb) c
Continuing.

-- at this point the disk starts to spin up, and my Ctrl+C doesn't
seem to get through to GDB. All I get is this lousy "Quit", i'm unable
to force it to interrupt --

Quit
(gdb) bt
#0 0x00007f800ff73c76 in poll () from /lib/libc.so.6
#1 0x00007f801130a010 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0x00007fff1d3f9e80 in ?? ()
#3 0x000000000098d590 in ?? ()
#4 0x0000000042673000 in ?? ()
#5 0x0000000000801000 in ?? ()
#6 0x00007fff1d3f9e70 in ?? ()
#7 0x00007fff1d3f9e80 in ?? ()
#8 0x00007f801130a010 in ?? () from /usr/lib/libglib-2.0.so.0
#9 0x000000000098d560 in ?? ()
#10 0x0000000000000000 in ?? ()

I'm not sure if the trace is happening at the right time, then.

[Alexander Jones (alex-weej)]

OK I think this is a problem with nautilus-open-terminal.

[Baptiste Mille-Mathias (bmillemathias)]

Alexander,

Could you give update on this bug, because I never had such problem.

[Christian Neumair (chris-gnome-de)]

Good catch, thanks for your bug report!

I think the issue is that we call
  g_find_program_in_path ("mc")
for finding out whether midnight commander is available as the menu items are generated. This call causes disk I/O.
However, I'd also like to allow users to install midnight commander at run-time without requiring them to re-start Nautilus. I wonder how a proper caching stratgy could look like. An alternative strategy would be to open a dialog offering to install MC if it hasn't been installed yet. I think I'll ask in my blog.

[Baptiste Mille-Mathias (bmillemathias)]

Hi Christian,

What is the status of this bug now?

[Launchpad Janitor (janitor)]

[Expired for nautilus-open-terminal (Ubuntu) because there has been no activity for 60 days.]