Closed Bug 436737 Opened 16 years ago Closed 16 years ago

.mozilla on a unfsd NFS mount leads to zero-sized .sqlite files and diverse range of failures

Categories

(Toolkit :: Storage, defect)

Product:
Toolkit
Component:
Storage
Version:
1.9.0 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: _deepfire, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008052418 Iceweasel/3.0 (Debian-3.0~rc1-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008052418 Iceweasel/3.0 (Debian-3.0~rc1-1)

My ~/.mozilla NFS share is served by unfsd, which
probably explains why no-one else seems to have this issue.

Nevertheless, this setup leads to nothing being ever written to the *.sqlite files (they persist at zero length), the URL bar, history and bookmarks non-functioning (i.e. cannot activate manually entered URLs, cannot use back/forward/reload buttons, due to them being grayed out, cannot add/import any bookmarks).

Reproducible: Always

Steps to Reproduce:
1. have your ~ on a NFS share served by unfsd, from the debian package unfs3, version 0.9.20+dfsg-2 (latest in sid)
2. start the browser
3a. enter anything in the URL bar, then attempt to make it follow
3b. click the home button, then attempt to click reload
3c. navigate from the homepage, then attempt to go back/forward
3d. attempt to bookmark something
Actual Results:  
nothing happens with the attempted actions

Expected Results:  
3a. the entered URL is loaded
3b. realoading actually happens
3c. back/forward buttons work
3d. bookmarked links actually appear in bookmarks

it all obviously stems from the dysfunction of the SQLite on unfsd.
Version: unspecified → 3.0 Branch
Status: UNCONFIRMED → NEW
Component: General → Storage
Ever confirmed: true
Product: Firefox → Toolkit
QA Contact: general → storage
Version: 3.0 Branch → 1.9.0 Branch
I'll note that debian uses system sqlite for firefox.  Do you know what version of sqlite you are running?
Forcing my NFS client to realize that locking was not possible by adding 'nolock' to the NFS share mounting args made things work for me.  From what I read, SQLite figures out what kind of locking is available and can fall back to dot-locking if less archaic locking forms are unavailable, but it appears that without that mount option it (or the NFS client) gets fooled into trying the standard locking mechanism.
This bug appeared after upgrading my nfs server. So I would say that it is a NFS bug, neither a SQLite nor a Firefox3 bug.

My NFS server is 2.2beta51 (SuSE 11.0) and SQLite is 2.8.17 (Ubuntu 8.04)

Note that adding "nolock" resolves the problem.
(In reply to comment #5)
> My NFS server is 2.2beta51 (SuSE 11.0) and SQLite is 2.8.17 (Ubuntu 8.04)
I don't think Firefox is using your system sqlite - we need a much newer version (3.5 at least)
I'm having this issue without changing any NFS settings on my Yellowdog linux 4 server. (It's not an nfs problem)

Also there is mention of sqlite which neither my NFS server nor the Suse 11 Linux client have installed. (it's not a sqlite problem unless you're talking about something within firefox)

Disabling file locking is not a suitable work around for me.  Furthermore the NFS server supports standard file locking AND none of these files are locked (I've wiped the entire .mozilla directory and reopened firefox to no avail)

This issue cripples firefox (can't hit enter to search or go to a URL you enter).
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0) Gecko/2008061600 SUSE/3.0-1.3 Firefox/3.0

Sorry forgot some details.  I'm on Suse linux 11 and have the mozilla repository added and have updated firefox to the latest (tried all 3 available firefox rpms from repositories I've configured).

I can reproduce this by simply moving the home dir to an NFS mount in the yast2 user manager.
Can you also reproduce this by using a binary from mozilla's web site?
I'll point out that by adding 'nolock' I wasn't disabling file locking - it
wasn't there to begin with.  unfsd doesn't provide file locking to NFS clients,
but it appears my NFS client wasn't smart enough to figure that out on its own.
 If you're using the kernel NFS server, then while your issue might be related
to this bug, we're struggling with the userspace server in particular.
Stupid me, I should have mentioned that but forgot.  It works fine with tar.gz compiled binaries directly from mozilla.  So this is likely a Suse 11 problem.  I'll go file something with them.  Sorry!
(In reply to comment #11)
> Stupid me, I should have mentioned that but forgot.  It works fine with tar.gz
> compiled binaries directly from mozilla.  So this is likely a Suse 11 problem. 
> I'll go file something with them.  Sorry!
No worries.  Please feel free to update this bug when you hear back from them so others who find this bug know what's going on!
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
(In reply to comment #12)
> (In reply to comment #11)
> > Stupid me, I should have mentioned that but forgot.  It works fine with tar.gz
> > compiled binaries directly from mozilla.  So this is likely a Suse 11 problem. 
> > I'll go file something with them.  Sorry!
> No worries.  Please feel free to update this bug when you hear back from them
> so others who find this bug know what's going on!
> 

While his problem may be with the SUSE binaries, neither Samium or I use SUSE.  Nick's problem wasn't with unfsd - isn't it a little premature to close this bug?
Well, given comment 4 and comment 5, it seems to be an NFS issue.  Samium hasn't commented since reporting, but I have a hunch that this is an NFS issue.
(In reply to comment #14)
> Well, given comment 4 and comment 5, it seems to be an NFS issue.  Samium
> hasn't commented since reporting, but I have a hunch that this is an NFS issue.

I tried to force a nolock mount, and yes, it solved the issue for me.

Thanks everybody and sorry for a late reply, I was on a vacation/in preparation..

I'm seeing the same issue here since installing Fedora 10 on my NFS client.
The NFS server is Centos 5.2 fully updated.

Before installing Fedora 10 I had Fedora 8 on my system using the same NFS server and never had an issue with Firefox like this.

After adding the "nolock" option to the NFS mount line in /etc/fstab Firefox works again as expected.
I'm in exactly the same situation as Bernd in comment 18
You need to log in before you can comment on or make changes to this bug.