GNU bug report logs -
#42151
[PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol
Previous Next
Full log
Message #23 received at 42151 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès writes:
Hi!
> "Jan (janneke) Nieuwenhuizen" <janneke <at> gnu.org> skribis:
>
>> $ guix offload test
>> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
>> guix offload: Guix is usable on 'childhurd' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
>> guix offload: 'childhurd' is running GNU Guile 3.0.4
>> guix offload: error: exception occurred on remote host 'localhost':
>> (%exception #<inferior-object #<&store-protocol-error message:
>> "setting synchronous mode: locking protocol" status: 1>>)
> Does it help if you set ‘settings.fsyncMetadata = false’ in the daemon?
> As a stop-gap, we could add a command-line option if that helps.
Tried that, thanks. No, it does not help. (But that's good news, see below!)
> The “synchronous = normal” mode translates to ‘fsync’ calls, right? If
> you rpctrace sqlite3, do you see ‘file_sync’ calls failing?
Tried that before, rpctrace hangs before I see something useful.
> Does sqlite pass its tests on GNU/Hurd?
That's the (or at least a) right question: YES!
> My 2¢!
Thanks -- it seems that buys us a pretty cheap fix after all, $-wise ;)
It turns out that Debian's patch (and thus this patch series) is
probably OK: It fixes the locking problem on the Hurd, while exposing
another bug, apparently: "unable to open database file".
It seems there is a compatibility bug/problem/thing with the db.sqlite
that we produce on GNU/Linux. While an unpatched sqlite3 on the Hurd
can read it, and work with it, the unpatched sqlite has locking
problems. I found a workaround, though: dumping and loading the
database file.
Look...
--8<---------------cut here---------------start------------->8---
$ scp childhurd2:/var/guix/db/db.sqlite db.sqlite-orig
db.sqlite 100% 144KB 5.8MB/s 00:00
11:30:37 janneke <at> dundal:~/tmp [env]
$ sqlite3 db.sqlite-orig .dump > db.dump
11:30:45 janneke <at> dundal:~/tmp [env]
$ sqlite3 -init db.dump db.sqlite-init .quit
-- Loading resources from db.dump
11:30:49 janneke <at> dundal:~/tmp [env]
$ cmp db.sqlite-orig db.sqlite-init
db.sqlite-orig db.sqlite-init differ: byte 19, line 1
[1]11:31:11 janneke <at> dundal:~/tmp [env]
$ scp db.sqlite-init childhurd2:/var/guix/db/db.sqlite
db.sqlite-init 100% 144KB 7.3MB/s 00:00
11:31:21 janneke <at> dundal:~/tmp [env]
$ guix offload test
guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
guix offload: Guix is usable on 'localhost' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
guix offload: 'localhost' is running GNU Guile 3.0.4
sending 1 store item (0 MiB) to 'localhost'...
exporting path `/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test'
guix offload: 'localhost' successfully imported '/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test'
retrieving 1 store item from 'localhost'...
guix offload: successfully imported '/gnu/store/gxz6hzyc1cy3m1w9l7f2dk6rcspvymxf-import-test' from 'localhost'
11:31:29 janneke <at> dundal:~/tmp [env]
--8<---------------cut here---------------end--------------->8---
So...about the compatibility problem. I tried to diff the db.sqlite-orig
db.sqlite-init binary files: they look completely different. Not sure
how to handle this workaround, maybe we can insert a two system* calls
somewhere when building the disk image?
Greetings,
Janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
This bug report was last modified 4 years and 316 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.