Solved Firefox, zero-length .sqlite files, and NFS/ZFS

[smj]

[ tl;dr - When configuring an NFS client, don't forget to add nfs_client_enable, rpc_lockd_enable, and rpc_statd_enable in /etc/rc.conf ... ]

Last week I decided to rebuild my primary desktop, going from 10.1 to 10.3. Installing the OS, the update to -p7, windowing system & window managers, et cetera, all went smoothly. Getting the NVidia drivers running was trivial, and audio and video "just worked." Test of Thunderbird and Firefox from the account created during installation -with local home directory - seemed okay. In normal use I have home and data directories NFS mounted from a FreeBSD 10.2-p9 server using ZFS.

I then login with my usual account, start Firefox, and the first thing shown is Sync complaining about cookies being disabled. No history, no bookmarks. Sigh, typical version upgrade BS...

I dig around looking for where and how to enable cookies so I can get Sync to restore my bookmarks, but the changes won't stick across restarts of Firefox. And I can't get sync past the cookies issue.

Eventually I shake my head, remove firefox (v47) and install firefox-esr (v45) - thinking I had some incompatibility in the latest version. But I saw the same behavior with this version.

Searching around for issues with preferences, Mozilla.org suggested several things. I set the profile to defaults - no change. I set aside the entire ~/.mozilla/firefox directory and let it create it all from scratch - no change.

With resetting the profile's preferences, I could see that the prefs.js file was being manipulated by the app. It wasn't something obvious like ownership or permissions. But I did eventually notice that all the SQLite data files in the profile were zero-length.

95 abort% ls -l *.sqlite
-rw-r--r--  1 smj  users  0 Aug 22 01:24 content-prefs.sqlite
-rw-r--r--  1 smj  users  0 Aug 22 12:16 cookies.sqlite
-rw-r--r--  1 smj  users  0 Aug 22 12:19 formhistory.sqlite
-rw-r--r--  1 smj  users  0 Aug 22 01:24 permissions.sqlite
-rw-r--r--  1 smj  users  0 Aug 22 01:24 places.sqlite
-rw-r--r--  1 smj  users  0 Aug 22 01:24 webappsstore.sqlite
96 abort%

It took me a while, but I eventually thought to check the local account:

root@abort:~yousir/.mozilla/firefox/4elu04kn.default # ls -l *.sqlite
-rw-r--r--  1 yousir  yousir  229376 Aug 21 00:09 content-prefs.sqlite
-rw-r--r--  1 yousir  yousir  524288 Aug 21 08:35 cookies.sqlite
-rw-r--r--  1 yousir  yousir  196608 Aug 21 04:10 formhistory.sqlite
-rw-r--r--  1 yousir  yousir  98304 Aug 21 00:09 permissions.sqlite
-rw-r--r--  1 yousir  yousir  10485760 Aug 21 04:16 places.sqlite
-rw-r--r--  1 yousir  yousir  393216 Aug 21 04:16 webappsstore.sqlite
root@abort:~yousir/.mozilla/firefox/4elu04kn.default #

Here are the versions I'm dealing with on the desktop:

97 abort% pkg info | grep firefox
firefox-esr-45.3.0,1  Web browser based on the browser portion of Mozilla
98 abort%
98 abort% pkg info | grep sqlite
py27-sqlite3-2.7.12_7  Standard Python binding to the SQLite3 library (Python 2.7)
qt4-sqlite-plugin-4.8.7_2  Qt SQLite 3 database plugin
rubygem-sqlite3-1.3.11  Ruby interface to the SQLite DB engine version 3
sqlite3-3.13.0  SQL database engine in a C library
99 abort%
99 abort% pkg info firefox-esr | grep sqlite
        libsqlite3.so.0
100 abort%

Obviously this was not a problem with 10.1... Any suggestions on what a next step would be here? Thanks!

 

[smj]

Also: Thunderbird doesn't scribble in it's .sqlite files as often as Firefox. But the cookies.sqlite file is now empty, whereas the cookies.sqlite.bak file last modified on Friday, before the upgrade, is 0.5MB...

Can anybody think of export/mount flags that might be needed from these symptoms?

 

[smj]

The SQLite FAQ suggests avoiding "multiple processes" accessing .sqlite files over NFS, but I haven't had that situation during the period in question. Since Friday, there's only been the one NFS client running any of these apps against the NFS-mounted home directory tree in question, and then only one instance of each app.

Edit: Using sqlite3(1) I can confirm that it will create files on a local ZFS filesystem, but not on the NFS mounted ZFS volume.

 

[smj]

Well this is embarrassing, but I'll leave the thread for others who may run into a similar problem in future.

The freshly rebuilt client machine had not been configured with the nfs_client_enable, rpc_lockd_enable, or rpc_statd_enable present in /etc/rc.conf. Added appropriate entries, rebooted, and the CLI test with sqlite3 works. Firefox happily scribbles in its .sqlite files.

Of course it was happily scribbling in JSON and JavaScript files all along without any locking, which is a little worrisome...

Thanks for the bandwidth.