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

Bug #216996 reported by Alexander Jones on 2008-04-13
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)
Ubuntu Desktop Bugs
nautilus-open-terminal (Ubuntu)

Bug Description

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
SourcePackage: nautilus
Uname: Linux 2.6.24-15-generic x86_64

Alexander Jones (alex-weej) wrote :
Sebastien Bacher (seb128) wrote :

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?

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete

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) wrote :

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

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

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

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

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

Changed in nautilus:
status: Incomplete → Invalid
description: updated


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

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.

Hi Christian,

What is the status of this bug now?

Changed in nautilus-open-terminal (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

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

Changed in nautilus-open-terminal (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers