Red Hat Bugzilla – Bug 174928
rhythmbox hangs on startup
Last modified: 2013-03-13 00:49:15 EDT
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):
Steps to Reproduce:
1. Start rhythmbox.
Rhythmbox hangs for about five minutes.
Rhythmbox does not hang.
Running "strace rhythmbox" shows that it hangs on the following system call:
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/
[levin@joh ~]$ time ls /net/foobar
ls: /net/foobar: No such file or directory
While running the command, the following is logged in /var/log/messages:
Dec 4 12:23:39 joh automount: >> mount clntudp_create: RPC: Port mapper
failure - RPC: Timed out
Dec 4 12:23:39 joh automount: lookup(program): lookup for foobar failed
Dec 4 12:23:39 joh automount: failed to mount /net/foobar
Dec 4 12:30:57 joh automount: >> mount clntudp_create: RPC: Port mapper
failure - RPC: Timed out
Dec 4 12:30:57 joh automount: lookup(program): lookup for foobar failed
Dec 4 12:30:57 joh automount: 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.
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?
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.