Firefox gives "The bookmarks and history system will not be functional

[CNBarnes]

OS: Ubuntu 10.4

I performed a routine "apt-get update", which apparently upgraded firefox to 3.6.14. If I start FF from the root account, everything works just fine. However, if I start FF from any normal user account, I get the error message:

"The bookmarks and history system will not be functional because one of Firefox's files is in use by another application. Some security software can cause this problem"

Running FF from root does not give the error (but then, who runs FF as root?).




I looked at link at support.mozilla.com/en-US/kb/The%20bookmarks%20and%20history%20system%20will%20 not%20be%20functional

And renamed the places.sqlite to places.sqlite.old as instructed.


Same error.

So I quit FF and completely wiped out the .mozilla folder. FF dutifully created a new .mozilla folder, then promptly gave me the exact same error message again. This STRONGLY indicates that it is not a permissions issue (besides, I looked at the permissions and everything in the .mozilla folder is owned by the user with at least rwx------ permissions...


Now I give up on this version of FF (3.6.14pre (Namoroka)) and apt-get remove it, then issue apt-get install firefox-3.5. It re-installed apt-get install firefox-3.5...
(the /etc/apt/sources.list file is attached).


I posed this question on the mozilla news server, but those folks seem somewhat *nix clueless.

Suggestions?

[elija]

I've not experienced this myself, but if rebooting fails, a working solution seems to be:

* shutting down firefox
* renaming places.sqlite to places_.sqlite
* starting firefox (it will create a new empty places.sqlite and do something else)
* shutting down firefox again
* deleting places.sqlite
* renaming places_.sqlite to places.sqlite
* starting firefox

(found here)

[CNBarnes]

I've not experienced this myself, but if rebooting fails, a working solution seems to be:

* shutting down firefox
* renaming places.sqlite to places_.sqlite
* starting firefox (it will create a new empty places.sqlite and do something else)
* shutting down firefox again
* deleting places.sqlite
* renaming places_.sqlite to places.sqlite
* starting firefox

(found)

If I'm not mistaken, I believe I said I did that in my OP when I wrote:

And renamed the places.sqlite to places.sqlite.old as instructed.

Same error.

So I quit FF and completely wiped out the .mozilla folder.

And then I said it didn't help....

[elija]

Ah but you didn't rename it back again

[CNBarnes]

Ah but you didn't rename it back again

*sigh*

The renaming it back again ONLY serves to resurrect the old bookmarks. At this point, I don't give a wit about saving the old files.... I just want the d*mn error message to quit.

[elija]

well, it worked for the person who made the post, so I'll assume that you could be bothered to try and say in that case, I don't know

[CNBarnes]

well, it worked for the person who made the post, so I'll assume that you could be bothered to try and say in that case, I don't know

A) the original post was from a year and half ago - I don't think that user was using 3.6-14pre.

B) Even though I knew full well what the results were going to be, I tried it. It did not work.

Ummm... a zero byte long file being replaced by another zero byte long file. I can't imagine why this inane suggestion didn't work.






I read that orginal post (which is duplicated in half a dozen other places).
It did NOT work.

[elija]

It's more to do with sqlite and how it handles locks which seems to be based on the actual inodes that are occupied. I suspect that the rename and rename back hack may have worked on the original sqlite file. A zero byte file may not react in the same way.

And therein my shouty friend lies the most important lesson here. When messing with config files always and without exception make sure you can go back to the original state.

[CNBarnes]

You're wrong. And I know you're wrong because I found the problem despite your insistence on trying to drag me down the wrong path.


The problem here had NOTHING, I repeat NOTHING to do with the user's ability to read or write to their own .mozilla directory. As it turns out, it has everything to do with the fact that NFS doesn't do file locking - something that was just fine w/ Ubuntu 10.04.

However, recall that I said we ran upgrades....

Apparently now the new kernel of Ubuntu now wants to attempt to do file locking w/ NFS.


Modifying the /etc/fstab from :

server:/home/users /home/users nfs rw,auto,nosuid,nodev 0 0

to

server:/home/users /home/users nfs rw,nolock,auto,nosuid,nodev 0 0

SOLVED the problem.

[elija]

Oh. It's on NFS. Yeah that changes things. Thanks for sharing that tidbit

Anyway glad you got it sorted