Bug 174928 - rhythmbox hangs on startup
Summary: rhythmbox hangs on startup
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rhythmbox (Show other bugs)
(Show other bugs)
Version: 5
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: John (J5) Palmieri
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-12-04 12:05 UTC by Levin Fritz
Modified: 2013-03-13 04:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-07 13:59:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Levin Fritz 2005-12-04 12:05:31 UTC
Description of problem:
After starting rhythmbox, the gui is displayed and then it hangs for about five
minutes. After that, it works fine.

Version-Release number of selected component (if applicable):
rhythmbox-0.9.1-1
autofs-4.1.4-14
portmap-4.0-65
kernel-smp-2.6.14-1.1735_FC5

How reproducible:
Always.

Steps to Reproduce:
1. Start rhythmbox.
  
Actual results:
Rhythmbox hangs for about five minutes.

Expected results:
Rhythmbox does not hang.

Additional info:
Running "strace rhythmbox" shows that it hangs on the following system call:
access("/net/iPod_Control/iTunes/iTunesDB", F_OK
There's no such file, in fact, /net is completely empty. Trying to open any file
in /net seems to trigger the problem:

[levin@joh ~]$ ls -l /net/
total 0

[levin@joh ~]$ time ls /net/foobar
ls: /net/foobar: No such file or directory

real    11m48.524s
user    0m0.000s
sys     0m0.004s

While running the command, the following is logged in /var/log/messages:
Dec  4 12:23:39 joh automount[5131]: >> mount clntudp_create: RPC: Port mapper
failure - RPC: Timed out
Dec  4 12:23:39 joh automount[5131]: lookup(program): lookup for foobar failed
Dec  4 12:23:39 joh automount[5131]: failed to mount /net/foobar
Dec  4 12:30:57 joh automount[5180]: >> mount clntudp_create: RPC: Port mapper
failure - RPC: Timed out
Dec  4 12:30:57 joh automount[5180]: lookup(program): lookup for foobar failed
Dec  4 12:30:57 joh automount[5180]: failed to mount /net/foobar

If eth0 is down (lo is the only network device), the problem does not occur. If
eth0 is up and I yank the ethernet cable, it does occur, though.

"ls /net/foobar" hangs on both my desktop machine, which runs fc5test1, and my
notebook, which runs fc4. rhythmbox doesn't hang on fc4, because it's an older
version that doesn't look at /net/iPod_Control/iTunes/iTunesDB.

I guess this is probably not rhythmbox's fault, but since I don't know what's
responsible for it, I'm filing under rhythmbox anyways.

Comment 1 John (J5) Palmieri 2005-12-05 18:22:54 UTC
if you have autofs running every time you look in /net autofs will try to mount
an associated nfs server (i.e. /net/my.nfs.server will try to mount
my.nfs.server).  This is what is taking Rythmbox so long to respond as it is
blocking on io.  The question now is why is it looking in /net?  Did you ever
configure this or is it a problem in our build?

Comment 2 Levin Fritz 2005-12-07 13:59:32 UTC
Okay, I figured it out: On startup, Rhythmbox goes through the list of mounted
volumes and pokes at each one to see if it happens to be an iPod. More
precisely, it looks for $mount_point/iPod_Control/iTunes/iTunesDB, which causes
autofs to look for an iPod_Control nfs server.

Version 0.9.2 of Rhythmbox checks the type of the volume first and ignore
volumes of type autofs, which solves my problem. Latest rawhide includes that
version, so I'm gonna close this as RAWHIDE.


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