bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

> "Jan (janneke) Nieuwenhuizen" <janneke@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@dundal:~/tmp [env]
$ sqlite3 db.sqlite-orig .dump > db.dump
11:30:45 janneke@dundal:~/tmp [env]
$ sqlite3 -init db.dump db.sqlite-init .quit
-- Loading resources from db.dump
11:30:49 janneke@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@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@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@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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com