Re: nfs home directory and google chrome.

[Kenneth Johansson <ken@kenjo.org>]

On 2020-10-07 15:10, J. Bruce Fields wrote:
> On Wed, Oct 07, 2020 at 12:54:50PM +0200, Kenneth Johansson wrote:
>> On 2020-10-06 20:14, J. Bruce Fields wrote:
>>> On Mon, Oct 05, 2020 at 10:07:56PM +0200, Kenneth Johansson wrote:
>>>> On 2020-10-05 18:46, Patrick Goetz wrote:
>>>>> We had a similar problem with Firefox, most notably with Mac OSX
>>>>> users who have NFS-mounted home directories. There's an
>>>>> about:config solution for Firefox; namely set
>>>>>
>>>>>     storage.nfs_filesystem: true
>>>>>
>>>>> This forces a specific network file locking mechanism which makes
>>>>> sqlite behave better. I'm guessing google chrome has something
>>>>> similar.
>>>>>
>>>> Since I have used chrome for years without any problems my guess it
>>>> that its something that changed with nfs in my setup.
>>>>
>>>> I did a strace and the first -EIO I get look like this
>>>>
>>>> fdatasync(94</home/kenjo/.config/google-chrome/Default/Login Data>)
>>>> = -1 EIO (Input/output error)
>>>>
>>>> then the same thing happens for other files like
>>>>
>>>> fdatasync(83</home/kenjo/.config/google-chrome/Default/Web Data>) =
>>>> -1 EIO (Input/output error)
>>>>
>>>> fdatasync(74</home/kenjo/.config/google-chrome/Default/History>) =
>>>> -1 EIO (Input/output error)
>>> Are you using soft mounts?
>>>
>>> (What are your mount options?)
>> auto.home /home autofs rw,relatime,fd=18,pgrp=2682,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=67621
>> 0 0
>>
>> /home/kenjo nfs4 rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,acregmin=120,acregmax=120,acdirmin=120,acdirmax=120,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.16.2.16,fsc,local_lock=none,addr=172.16.2.6
>> 0 0
>>
>> what I actualy set manually in auto.home is
>>
>> -tcp,fsc,noatime,ac,actimeo=120
> OK, that looks fine.
>
> Maybe I overlooked the obvious: if Chrome holds a lock on that file when
> you suspend, and if you stay in suspend for longer than the NFSv4 lease
> time (default 90 seconds), then the client will lose its lease, hence
> any file locks.  I think these days the client then returns EIO on any
> further IO to that file descriptor.

So I tested by just pulling the network cable for a few minutes and the 
effect is the same. this time the password  database survived but the 
history went bye bye.

History sqlite error 1034, errno 5: disk I/O error, sql: COMMIT

The real problem here is that chrome destroys the database file and do 
not communicate that there is a problem to the end user unless started 
from a terminal and it can't recover ever. If it had just removed the 
file and recreated a new one from the server it would not be a big 
problem. What the user notice is that password handling and form filling 
do work very poorly and the only solution is really  "rm -rf  
~/.config/google-chrome/" to force it to recreate the files.


> Maybe there's some way to turn off that locking as a workaround.
>
> The simplest thing we can do to help might be implementing "courteous
> server" behavior: instead of automatically removing locks after a
> client's lease expires, it can wait until there's an actual lock
> conflict.  That might be enough for your case.
>
> There's been a little planning done and it's not a big project, but I
> don't think it's actually at the top of anyone's todo list right now, so
> I'm not sure when that will get done.
>
> --b.
>
>>
>>> --b.
>>>
>>>>
>>>>
>>>>> On 10/4/20 6:53 AM, Kenneth Johansson wrote:
>>>>>> So I have had for a long time problems with google chrome and
>>>>>> suspend resume causing it to mangle its sqlite database.
>>>>>>
>>>>>> it looks to only happen if I use nfs mounted home directory. I'm
>>>>>> not sure exactly what is happening but lets first see if this
>>>>>> happens to anybody else.
>>>>>>
>>>>>> How to get the error.
>>>>>>
>>>>>> 1. start google from a terminal with "google-chrome"
>>>>>>
>>>>>> 2. suspend the computer
>>>>>>
>>>>>> 3. wait a while. There is some type of minimum time here I do
>>>>>> not know what its is but I basically get the error every time of
>>>>>> I suspend in evening and resume in morning
>>>>>>
>>>>>> 4. look for printout that looks like something like this
>>>>>>
>>>>>> [16789:18181:1004/125852.529750:ERROR:database.cc(1692)]
>>>>>> Passwords sqlite error 1034, errno 5: disk I/O error, sql:
>>>>>> COMMIT
>>>>>> [16789:16829:1004/125852.529744:ERROR:database.cc(1692)] Web
>>>>>> sqlite error 1034, errno 5: disk I/O error, sql: COMMIT
>>>>>> [16789:16829:1004/125852.530261:ERROR:database.cc(1692)] Web
>>>>>> sqlite error 1034, errno 5: disk I/O error, sql: INSERT OR
>>>>>> REPLACE INTO autofill_model_type_state (model_type, value)
>>>>>> VALUES(?,?)
>>>>>> [16789:16789:1004/125852.563571:ERROR:sync_metadata_store_change_list.cc(34)]
>>>>>> Autofill datatype error was encountered: Failed to update
>>>>>> ModelTypeState.
>>>>>> [16789:19002:1004/125902.534103:ERROR:database.cc(1692)] History
>>>>>> sqlite error 1034, errno 5: disk I/O error, sql: COMMIT
>>>>>> [16789:19002:1004/125902.536903:ERROR:database.cc(1692)]
>>>>>> Thumbnail sqlite error 778, errno 5: disk I/O error, sql: COMMIT
>>>>>>
>>>>>>
>>>>>> [16789:19002:1004/130044.120379:ERROR:database.cc(1692)]
>>>>>> Passwords sqlite error 1034, errno 5: disk I/O error, sql:
>>>>>> INSERT OR REPLACE INTO sync_model_metadata (id, model_metadata)
>>>>>> VALUES(1, ?)
>>>>>> [16789:16829:1004/130044.120388:ERROR:database.cc(1692)] Web
>>>>>> sqlite error 1034, errno 5: disk I/O error, sql: INSERT OR
>>>>>> REPLACE INTO autofill_model_type_state (model_type, value)
>>>>>> VALUES(?,?)
>>>>>>
>>>>>>
>>>>>> and so on.  if you use google sync you can also check
>>>>>> "chrome://sync-internals" to see if something is wrong with the
>>>>>> database.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> This message is from an external sender. Learn more about why this <<
>>>>>>>> matters at https://links.utexas.edu/rtyclf. <<