Ubuntu
nfs-utils package

firefox locked or lost settings after crash

Bug #343788 reported by Sam Liddicott
30
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
Medium
firefox-3.0 (Ubuntu)
Invalid
Undecided
Unassigned
nfs-utils (Ubuntu)
Confirmed
Undecided
khaled_frht@yahoo.com

Bug Description

Binary package hint: firefox-3.0

See also bug Bug #224513

I use firefox with NFS home directories. Sometimes network connectivity is lost or firefox crashes.

The result is
1. that firefox will never run again without severe intervention
2. it looses all settings.

The non-trivial intervention is reduced to:
rm -f .mozilla/*/lock .mozilla/*/.parentlock

and then it starts, but all the settings are missing, page navigation doesn't work properly and bookmarks are missing.

The better fix is:

mv .mozilla/firefox .mozilla/firefox.old
then start firefox and import the bookmarks from .mozilla/firefox.old/*/bookmarkbackups

which just leaves the case of everything else missing.

I've had this problem ever since sqlite was used for storing configuration and now I'm fed up with it.

It seems like sqlite is only suitable for local storage.

If firefox insists on using it, I wish it would be more robust, my family are gnashing their teeth over it and so am I

Revision history for this message
Daniel Hollocher (chogydan) wrote :

if you don't think this bug needs confirmation in Ubuntu, you could go straight to filing this bug upstream: https://bugzilla.mozilla.org/

Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030516 Ubuntu/9.04 (jaunty) Firefox/3.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030516 Ubuntu/9.04 (jaunty) Firefox/3.0.7

Possibly related to Bug 452193, Bug 431558 and others.

I use firefox with NFS home directories. Sometimes network connectivity is lost for the session, or firefox crashes.

The result is
1. that firefox will never run again without severe intervention
2. it looses all settings.

The non-trivial intervention may be reduced to:
rm -f .mozilla/*/lock .mozilla/*/.parentlock

and then it starts, but all the settings are missing, page navigation doesn't work properly and bookmarks are missing.

The better fix is:

mv .mozilla/firefox .mozilla/firefox.old
then start firefox and import the bookmarks from .mozilla/firefox.old/*/bookmarkbackups

which just leaves the case of all other preferences and certificates missing.

I've had this problem ever since sqlite was used for storing configuration and now I'm fed up with it.

It seems like sqlite is only suitable for local storage.

If firefox insists on using it, I wish it would be more robust, my family are gnashing their teeth over it and so am I

Reproducible: Always

Steps to Reproduce:
1. have a merry browsing session with NFS home directories
2. pull out the network cable and ctrl-alt-sysreq-b
3. reboot and try and use firefox
Actual Results:
Claims firefox is already running.
It's bad enough that the lock file is a symlink to something as uselss as:
127.0.1.1:+27801
 - a hostname would be more useful - or perhaps a combination of hostname's IP and hostname - but thats not the real problem

Expected Results:
Firefox might work or tell me something useful about where it is supposedly running.
Deleting the lock files should not result in missing bookmarks and broken toolbar buttons requiring a new firefox profile.

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

Isn't this a dupe of the NFS is lying to us bug ?

Revision history for this message
In , Shawn Wilsher (sdwilsh) wrote :

(In reply to comment #1)
> Isn't this a dupe of the NFS is lying to us bug ?
 This is worse than that bug because apparently the .parentlock file is still around.

Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote :

In case it matters, my NFS mount options are:

defaults,_netdev,soft,bg,intr,noatime which expanded to
rw,noatime,soft,bg,intr

I think also this is related to:
 Bug 478189 - corrupt profile on unexpected computer restarts (over nfs)
 Bug 463394 - Profile destroyed on nfs mounted homedir, os crash

My homedirs are exported "sync" as this is the default for nfs.

Revision history for this message
John Vivirito (gnomefreak) wrote :

Does running firefox using the following command help?
firefox-3.0 --safe-mode
can you please list all extensions you have.

Changed in firefox-3.0 (Ubuntu):
status: New → Incomplete
Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

so, i'm confused.

reporter: if you tell your nfs (whichever) to use nolock, does this problem still occur?

Revision history for this message
Sam Liddicott (sam-liddicott) wrote :

I posted upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=483676

Starting in safe mode
* does not solve the lock and .parentlock problem
* does not make the back/forward buttons in the toolbar
* clicking the "restore bookmarks" etc buttons, does not work

like the famous goggles - they do nothing!

The only addon is the ubuntu addon.

Daniel Hollocher (chogydan)
Changed in firefox-3.0:
status: Incomplete → New
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unknown → New
Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote :

I've tried twice to re-produce this problem with nolock and failed.
This surprises me very much.

I'll try again on some of the wireless machines, and let you know how they go.

(What confused you?)

Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote :

Well I think I can confirm that setting nolock on my nfs mount solves this problem; thanks.

Whats the story behind this?

Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote :

nolock seems like bad news,
and lets the same user run more than one firefox session from multiple logins - is this also likely to corrupt sessions?

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

gecko has a lock for the profile directory, so in general it shouldn't step on another gecko that's using places, however a random application could.

Revision history for this message
In , Cwyse (cwyse) wrote :

I tested the nolock option and it seems to fix things. However my users are constantly using files from each other directions for software rendering, so nolock is not a safe option for us. Can mozilla possible do something to resolve this issue without changing the nfs locking of the users home directory?

Revision history for this message
In , Shawn Wilsher (sdwilsh) wrote :

Bug 484883 may help, but I'm not sure.

Revision history for this message
In , Shawn Wilsher (sdwilsh) wrote :

(In reply to comment #9)
> I tested the nolock option and it seems to fix things. However my users are
> constantly using files from each other directions for software rendering, so
> nolock is not a safe option for us. Can mozilla possible do something to
> resolve this issue without changing the nfs locking of the users home
> directory?
 No, we can't do anything about this sadly. This bug is with NFS.

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: New → Invalid
Revision history for this message
Micah Gersten (micahg) wrote :

Mozilla Upstream said this was a problem with NFS. Please assign to appropriate NFS package if this is not the correct one.

Changed in firefox-3.0 (Ubuntu):
status: New → Invalid
Revision history for this message
David Edwards (purple52) wrote :

I suffer from the same problem - the only way I've found of returning things to normal is to run "sudo /etc/init.d/nfs-kernel-server restart" on my NFS server and then delete the FF lock files. Obviously this causes an interruption in the availability of NFS, and if you're using an NFS mounted home folder I've found this can lock up your X session on the client - so safest to log out of clients before the restart.

Revision history for this message
Sam Liddicott (sam-liddicott) wrote : RE: [Bug 343788] Re: firefox locked or lost settings after crash

I disagree with the "invalid".

The cause may be nfs, or the cause may be an nfs client crashing or losing network connection, but then the problem is wth firefox.

Currenly I manually remove my profile and lose my history, bookmarks, client certs and everything.

There is a problem with firefox if firefox can get rendered useless through such an occasion.

It ought to be able to recover - even with data loss.

Revision history for this message
Micah Gersten (micahg) wrote :

@Sam Liddicott

I'd like the opinion of the NFS maintainers before pushing Mozilla for more information. They will usually take responsibility if it's a problem they can fix. I am still subscribed and will watch the progress of this bug.

Revision history for this message
Niall Brosnan (niallb) wrote :

I have a larger number of users on the system that brought me to this bug,
so restarting the NFS service isn't convenient as a regular solution.

I experienced this problem today for the first time in months. Jaunty client, feisty server, nfsv3.
Firefox 3.0.13 failed after a power interruption to load bookmarks and other profile characteristics.
I simultaneously experienced OpenOffice 3.1.0 (ppa) go into a file recovery loop.

The following procedure restored expected behaviour to both firefox and openoffice,
so it would seem to me to be filesystem based. I will post back if the situation recurs,
but I'm not in a position to 'encourage it' with a live server.
The misbehaving instances of firefox and openoffice were closed before tarballing.,
and required no unusual input after restarting them.
history, bookmarks and certs all checked and functioning.

tar cvf firefox-openoffice-rc.tar .mozilla/ .openoffice.org/
rm -rf .mozilla/ .openoffice.org/
tar xvf firefox-openoffice-rc.tar

Revision history for this message
Valentijn Sessink (valentijn) wrote :

NFSv4 will help: it does notice a no longer held lock, in contrast to NFSv3, that will not notice a no longer held lock (and will hold the lock indefinately).

The problem is, that even after removing lock and .parentlock, a couple of .sqlite files will still be locked on an NFSv3 server.

A workaround we used is to copy the whole profile, then rename the new profile to go over the old one; then remove the old profile. The new profile will have no locked files on the server, so it will work.

khaled_frht@yahoo.com (khaled-frht)
Changed in nfs-utils (Ubuntu):
assignee: nobody → khaled_frht@yahoo.com (khaled-frht)
status: New → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.