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. <<
