Closed Bug 530332 Opened 16 years ago Closed 16 years ago

History and cookies lost over NFS (sqlite locking)

Categories

(Firefox :: Bookmarks & History, defect)

3.5 Branch
x86
Linux
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 436737

People

(Reporter: w, Unassigned)

Details

(Keywords: user-doc-needed)

User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.4) Gecko/20091113 SeaMonkey/2.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 After upgrading to firefox 3.5.5 and seamonkey 2.0, I noticed that my location bar would never propose me any history. and that any cookies were lost after a restart. Running firefox through strace shows many failed fcntl calls to various sqlite files. So I wrote a simple library that I'm using to fake the locks, and I can confirm it fixes all the problems : $ LD_PRELOAD=$PWD/nolock.so firefox $ cat nolock.c #include <asm/unistd.h> #include <unistd.h> #include <fcntl.h> #include <stdarg.h> int fcntl(int fd, int cmd, ...) { void *arg; va_list ap; if (cmd == F_SETLK) return 0; va_start(ap, cmd); arg = va_arg(ap, void *); va_end(ap); return syscall(__NR_fcntl, fd, cmd, arg); } While this works, this is far from being an acceptable long-term solution for all workplaces running over NFS. The launcher scripts could be adapted to detect NFS homes and pre-load the code above before starting mozilla-bin, but in the long term, we should find a cleaner solution. The issue comes from the recent use of SQLite, which explicitly states that it does not work over NFS due to locks. This is a bit of a shame, considering the number of people using NFS at home or work. Maybe SQLite can be adapted not to lock, or to use heavier locks (files) ? I'm going back to Seamonkey 1.1.18, but I'm open to re-install to test various workarounds. Reproducible: Always Steps to Reproduce: 1. start firefox 3.5/seamonkey 2.0 with a NFS-mounted home 2. visit google.com 3. check that you have some cookies 4. exit 5. restart the browser 6. verify that you don't have any google.com entry in your location bar 7. verify that you don't have any google cookies in your cookie manager Actual Results: History was not kept across restarts, neither were the cookies. Firefox may even complain that another program is already using the profile and that the history will not be used. Doing the same scenario with the LD_PRELOAD trick above does not exhibit the issue at all. Expected Results: It should have kept history and cookies. An example of strace of firefox failing to lock places.sqlite : 29845 access("/users/willy/.mozilla/firefox/bojq4llc.default/places.sqlite", F_OK) = 0 29845 open("/users/willy/.mozilla/firefox/bojq4llc.default/places.sqlite", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 26 29845 fcntl64(26, F_GETFD) = 0 29845 fcntl64(26, F_SETFD, FD_CLOEXEC) = 0 29845 fstat64(26, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 29845 dup(26) = 29 29845 fcntl64(26, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=1}) = -1 ENOLCK (No locks available) 29845 lseek(26, 0, SEEK_SET) = 0 29845 read(26, ""..., 100) = 0 29845 fcntl64(26, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, len=1}) = -1 ENOLCK (No locks available) 29845 close(26) = 0
Version: unspecified → 3.5 Branch
bug 436737 mentions a workaround
Yeah, this looks like a duplicate of bug 436737 to me
Indeed, I can confirm that remounting with "nolock" also fixes the issue. This should go somewhere in a FAQ in my opinion, because I've reviewed about 20 other bugs before posting and couldn't find a fix, though I could find other related bugs. Thanks! willy
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
(In reply to comment #3) > Indeed, I can confirm that remounting with "nolock" also fixes the issue. This > should go somewhere in a FAQ in my opinion, because I've reviewed about 20 > other bugs before posting and couldn't find a fix, though I could find other > related bugs. > > Thanks! > willy Willy, you can add a page about it to the Support site, then others can enjoy the benefits of your discovery: http://support.mozilla.com/en-US/kb/.
You need to log in before you can comment on or make changes to this bug.