Firefox Troubleshooting under Linux
We are currently in the process of migrating our HOWTO articles to a new CCIS Knowledgebase. The content of this page has been moved to the following KB article:
Click here to expand the deprecated HOWTO page
Short of the terminal, Firefox is probably the most important non-development-specific Linux application to most users of the CCIS Linux environment. Unfortunately, for a number of reasons, it’s also one of the most prone to mysterious problems. This HOWTO describes how to troubleshoot and work around those problems. It’s sort of a FAQ for Firefox problems.
Firefox cannot use the profile “…” because it is in use.
This and similar errors can mean one of two things: Either you actually do have an existing instance of Firefox running (perhaps on another machine), or else there is a stale lock file left over from a previous invocation of Firefox (again, perhaps on another machine) that quit or died without cleaning up after itself.
The first thing to do is to is to find all the Firefox lock files. These are named either lock or .parentlock, and they will be a couple levels under the .mozilla directory in your home directory. To find them, run the commands
cd find .mozilla/firefox -name "*lock" -ls
(The cd is just to make sure you’re already in your home directory when the find command runs. You need quotation marks around *lock because the * character is treated specially by the shell. You could also use ls -l .mozilla/firefox/*/lock followed by ls -l .mozilla/firefox/*/.parentlock if you like that better than find, but make sure you deal with both kinds of lock files.)
Example output from that find command might look something like this:
25167307 0 lrwxrwxrwx 1 you majors 20 Nov 5 13:38 .mozilla/firefox/3xamP13.default/lock -> 22.214.171.124:+1337 8827268 0 -rw-r--r-- 1 you majors 0 Nov 5 14:07 .mozilla/firefox/3xamP13.default/.parentlock
(Scroll right if needed to make sure you see the end of the first line.)
.parentlock is only used as a lock file. But lock is a broken symbolic link whose target (the part after the -> in the output) tells you where Firefox thinks it’s running. The first part, 126.96.36.199, is the IP address of the machine Firefox thinks it’s running on; you can type
to find out what machine that is. In this example it’s login. The last number (1337) is the process ID of the old Firefox process that Firefox thinks is still running. You can either use
ps x | grep firefox on that machine to see if there’s still a firefox running with that process ID, or (if the machine is the one you’re sitting at) you can use the System Monitor app available from the GNOME menu at System > Administration > System Monitor to look at the processes and see if the Firefox is still running with that ID.
If there is a Firefox running on that machine with that process ID, then you need to quit it before you can remove the lock files (if they don’t go away automatically). See the section below, How to kill Firefox…, for how to do that.
Once you’ve either killed the running Firefox or determined that the Firefox process pointed at by the lock file does not actually exist any more, you can delete the lock files. Be sure you delete both the lock and .parentlock files. In our example from above, the commands would be
rm .mozilla/firefox/3xamP13.default/lock rm .mozilla/firefox/3xamP13.default/.parentlock
Then you should be able to start a new Firefox normally.
Trying to do things produces weird error messages about search engines
Sometimes, you’ll find that various attempts to do things with Firefox (open new pages, for instance, or sometimes even close windows or quit Firefox from the menu) produce strange error messages, usually about missing search-engine files. This tends to be a problem for faculty and grad students with Systems-supported Linux boxes on their desks, not for lab users, because it happens when Firefox has been upgraded while it was running, and upgrades normally happen at night, so it’s likeliest to happen if you leave Firefox running overnight.
You can fix this problem by quitting Firefox and restarting it. (Unfortunately, because of the nature of this problem, sometimes the Quit menu entry doesn’t work. In that case, see How to kill Firefox, if it’s not responding below.)
You can avoid this by quitting Firefox before you leave for the night, since upgrades happen at night. (If you tell Firefox to save all your tabs and windows when you quit, then they’ll all open automatically when you start it the next morning, which is almost as convenient as leaving Firefox running.) If you leave Firefox running all the time, though, you can expect to have to kill and restart it because of this problem roughly once a month, on average.
This is unfortunate, but it’s a necessary consequence of automatically applying security fixes on a regular basis — Firefox is complex enough that it often has trouble when it’s updated while it’s already running. (It’s also complex enough that it tends to need a lot of security fixes.)
How to kill Firefox, if it’s not responding
If a Firefox process is running and responding normally, and you’re sitting at the screen of the machine it’s running on, you can of course just choose File > Quit to tell it to quit. Otherwise, there are two other ways:
Even if Firefox is not responding, you can kill it using the System Monitor if you’re sitting at the machine it’s running.
You can get to the System Monitor application via System > Administration > System Monitor from the GNOME panel at the top of the screen. This opens a window with several tabs; the “Processes” tab shows you the currently running processes in alphabetical order. You can look for “firefox” in that list (scrolling if necessary), select it, and click the “End Process” button to kill it. (You’ll need to confirm.) Again, depending what state Firefox is in, this might leave lock files around that you’ll need to destroy.
On the command line
The command-line way works whether or not Firefox is responding, and it works whether you’re sitting at the machine Firefox is running on or logged in remotely. Just type
in a terminal window (which you can get by choosing Applications > Accessories > Terminal from the GNOME panel at the top of the screen).
Occasionally, if Firefox is really badly hung, you may need to use
killall -9 firefox< after typing the above. However, that doesn’t give Firefox a chance to remove its lock files, so you are very likely to need to remove them (see above) before Firefox will start properly again.
You can see all your currently-running Firefox jobs with the command
ps x | grep firefox
(but note that, depending on timing, that may also show you the
grep firefox command itself, and may show you any other commands running with “firefox” in their name or arguments).