* bug#35874: “guix pull” fails on setlocale @ 2019-05-23 21:01 Ricardo Wurmus [not found] ` <handler.35874.B.155864531425074.ack@debbugs.gnu.org> 0 siblings, 1 reply; 7+ messages in thread From: Ricardo Wurmus @ 2019-05-23 21:01 UTC (permalink / raw) To: 35874 Hi Guix, I’m getting this weird error on “guix pull”: --8<---------------cut here---------------start------------->8--- [rwurmus@max147.mdc-berlin.net:~] $ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git e26d628 Computing Guix derivation for 'x86_64-linux'... \@ build-started /gnu/store/pryjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv - x86_64-linux /gnu/var/log/guix/drvs/pr//yjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv 2110 |@ build-log 2110 252 Backtrace: 2 (primitive-load "/gnu/store/lgad0sg02p56jadwqrq674250d5?") In ice-9/eval.scm: 619:8 1 (_ #f) In unknown file: 0 (setlocale 6 "en_US.utf8") ERROR: In procedure setlocale: In procedure setlocale: Invalid argument builder for `/gnu/store/pryjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv' failed with exit code 1 @ build-failed /gnu/store/pryjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv - 1 builder for `/gnu/store/pryjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv' failed with exit code 1 cannot build derivation `/gnu/store/nj6zd6gn3x1rf08ayxxwd1v0fyg71v9c-libgit2-0.28.2.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/82x55s3m26j3rpq45ppijzvvh3rhxhsb-guile-git-0.2.0.drv': 1 dependencies couldn't be built Backtrace: In ./guix/store.scm: 1667:8 19 (_ _) 1667:8 18 (_ _) In ./guix/gexp.scm: 708:2 17 (_ _) In ./guix/monads.scm: 482:9 16 (_ _) In ./guix/gexp.scm: 573:13 15 (_ _) In ./guix/store.scm: 1667:8 14 (_ _) In ./guix/gexp.scm: 708:2 13 (_ _) In ./guix/monads.scm: 482:9 12 (_ _) In ./guix/gexp.scm: 573:13 11 (_ _) In ./guix/store.scm: 1667:8 10 (_ _) In ./guix/gexp.scm: 708:2 9 (_ _) In ./guix/monads.scm: 482:9 8 (_ _) In ./guix/gexp.scm: 573:13 7 (_ _) In ./guix/store.scm: 1667:8 6 (_ _) 1690:38 5 (_ #<store-connection 256.99 d5cfb40>) In ./guix/packages.scm: 936:16 4 (cache! #<weak-table 420/883> #<package guile-git@0.2.?> ?) In ./guix/grafts.scm: 314:4 3 (graft-derivation #<store-connection 256.99 d5cfb40> # # ?) 192:4 2 (references-oracle #<store-connection 256.99 d5cfb40> #) 201:20 1 (_ _ _) In ./guix/store.scm: 1203:15 0 (_ #<store-connection 256.99 d5cfb40> _ _) ./guix/store.scm:1203:15: Throw to key `srfi-34' with args `(#<condition &store-protocol-error [message: "build of `/gnu/store/82x55s3m26j3rpq45ppijzvvh3rhxhsb-guile-git-0.2.0.drv' failed" status: 100] d59ede0>)'. guix pull: error: You found a bug: the program '/gnu/store/2mjaq8zxq60ifqxj3fra7f8gyxxccypm-compute-guix-derivation' failed to compute the derivation for Guix (version: "e26d628b0fabf5a0aa7c4164a9558c66c61e02ab"; system: "x86_64-linux"; host version: "ebd45195dd10eea9ce2c563697989bd4b27dfdd3"; pull-version: 1). Please report it by email to <bug-guix@gnu.org>. --8<---------------cut here---------------end--------------->8--- I’m using “guix” from the result of a previous “guix pull”, but it’s the same if I use a git checkout. The daemon is probably a little special. I’m using the daemon from a git checkout inside of an environment for “guix”, because localstatedir in my case is /gnu/var. I also tried using the daemon from the same “guix pull” tree, after setting GUIX_DATABASE_DIRECTORY=/gnu/var/guix/db and GUIX_STATE_DIRECTORY=/gnu/var/guix. Here’s how I launch the daemon: --8<---------------cut here---------------start------------->8--- #!/bin/bash export GUIX_PROFILE=/gnu/var/guix/profiles/custom/guix-remote/.guix-profile # We need this to augment the GUILE_LOAD_PATH such that it includes # the Guile bindings to gnutls. Sourcing the whole profile is # overkill, but who cares, eh? source ${GUIX_PROFILE}/etc/profile # Fix locale warnings export GUIX_LOCPATH=${GUIX_PROFILE}/lib/locale # Fix certificate validation export SSL_CERT_DIR=${GUIX_PROFILE}/etc/ssl/certs/ #export GUIX_DATABASE_DIRECTORY=/gnu/var/guix/db #export GUIX_STATE_DIRECTORY=/gnu/var/guix #/gnu/remote/.guix-pull/bin/guix-daemon \ #/gnu/remote/guix/pre-inst-env guix-daemon \ exec /gnu/remote/guix/pre-inst-env guix-daemon \ --disable-log-compression \ --build-users-group=guix-builder \ --listen=141.80.186.209:9999 \ --substitute-urls="https://berlin.guixsd.org https://mirror.hydra.gnu.org" $@ --8<---------------cut here---------------end--------------->8--- All communication with the daemon happens over network; the local socket is not involved, but this doesn’t seem to make any difference here. The simplest reproducer is to run Guile where the daemon runs and to evaluate setlocale: --8<---------------cut here---------------start------------->8--- [rwurmus@guix-builder:~] (716) $ /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4/bin/guile guile: warning: failed to install locale warning: failed to install locale: Invalid argument GNU Guile 2.2.4 Copyright (C) 1995-2017 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (setlocale 6 "en_US.utf8") ERROR: In procedure setlocale: In procedure setlocale: Invalid argument Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> --8<---------------cut here---------------end--------------->8--- This is expected because GUIX_LOCPATH isn’t set in this environment. It’s fine when I set GUIX_LOCPATH to the value it has in the above guix-daemon wrapper: --8<---------------cut here---------------start------------->8--- [rwurmus@guix-builder:~] (719) $ GUIX_LOCPATH=/gnu/var/guix/profiles/custom/guix-remote/.guix-profile/lib/locale /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4/bin/guile GNU Guile 2.2.4 Copyright (C) 1995-2017 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (setlocale 6 "en_US.utf8") $1 = "en_US.utf8" scheme@(guile-user)> --8<---------------cut here---------------end--------------->8--- I don’t understand why Guile as used in the builder of libgit2-0.28.tar.xz would behave any different as the daemons environment looks fine to me: --8<---------------cut here---------------start------------->8--- [rwurmus@guix-builder:~] (723) $ sudo strings /proc/27562/environ GUIX_LOCPATH=/gnu/var/guix/profiles/custom/guix-remote/.guix-profile/lib/locale NIX_BUILD_HOOK=/gnu/remote/guix/nix/scripts/offload NIX_HASH= NIX_LIBEXEC_DIR=/gnu/remote/guix/nix/scripts LC_ALL=en_US.UTF-8 GUILE_LOAD_PATH=/gnu/remote/guix:/gnu/remote/guix:/gnu/var/guix/profiles/custom/guix-remote/.guix-profile/share/guile/site/2.2 GUIX_PROFILE=/gnu/var/guix/profiles/custom/guix-remote/.guix-profile GUILE_LOAD_COMPILED_PATH=/gnu/remote/guix:/gnu/var/guix/profiles/custom/guix-remote/.guix-profile/lib/guile/2.2/site-ccache PATH=/gnu/remote/guix/scripts:/gnu/remote/guix:/gnu/var/guix/profiles/custom/guix-remote/.guix-profile/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin PWD=/ LANG=en_US.UTF-8 SSL_CERT_DIR=/gnu/var/guix/profiles/custom/guix-remote/.guix-profile/etc/ssl/certs/ SHLVL=0 NIX_ROOT_FINDER=/gnu/remote/guix/nix/scripts/list-runtime-roots GUIX_UNINSTALLED=1 --8<---------------cut here---------------end--------------->8--- What’s going on here? -- Ricardo ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <handler.35874.B.155864531425074.ack@debbugs.gnu.org>]
* bug#35874: “guix pull” fails on setlocale [not found] ` <handler.35874.B.155864531425074.ack@debbugs.gnu.org> @ 2019-05-23 21:40 ` Ricardo Wurmus 2019-05-24 13:49 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: Ricardo Wurmus @ 2019-05-23 21:40 UTC (permalink / raw) To: 35874 This is a store corruption bug. The problem appears to be that I accidentally ran the daemon with the wrong GUIX_DATABASE_DIRECTORY. The localstatedir is /gnu/var, not /var. In an attempt to simplify my complicated cluster setup, I wanted to switch from the git checkout to “guix pull”. I was able to use the Guix client from “guix pull”, but not the daemon, because of the localstatedir difference. When I started the daemon from “guix pull” without having set GUIX_DATABASE_DIRECTORY and I asked Guix to build something I noticed this error message: guix pull: error: cannot unlink `/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/gconv': Directory not empty Wait, “unlink”? Of course: when a build is not found in the database, but the store contains an item of the same name the daemon will remove the existing directory. In my case, the daemon did not realize that it couldn’t ever find anything interesting in the database, because it looked in the wrong localstate directory. So it partially removed store items and then aborted, leaving the store in a broken state. Can we make the daemon detect that its understanding of the site differs from that of the Guix client? -- Ricardo ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#35874: “guix pull” fails on setlocale 2019-05-23 21:40 ` Ricardo Wurmus @ 2019-05-24 13:49 ` Ludovic Courtès 2019-05-24 14:11 ` Ricardo Wurmus 0 siblings, 1 reply; 7+ messages in thread From: Ludovic Courtès @ 2019-05-24 13:49 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: 35874 Hello Ricardo, Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis: > This is a store corruption bug. > > The problem appears to be that I accidentally ran the daemon with the > wrong GUIX_DATABASE_DIRECTORY. The localstatedir is /gnu/var, not /var. Ouch. :-/ > When I started the daemon from “guix pull” without having set > GUIX_DATABASE_DIRECTORY and I asked Guix to build something I noticed > this error message: > > guix pull: error: cannot unlink `/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/gconv': Directory not empty When you do ‘guix pull’, the resulting (guix config) is supposed to honor the settings of the calling ‘guix’: %localstatedir, etc. It seems that it wasn’t the case here? Could you try again running ‘guix pull’ from a ‘guix’ command that has non-default settings and check the resulting (guix config) module? > Can we make the daemon detect that its understanding of the site differs > from that of the Guix client? I don’t see how that could be done. The daemon necessarily assumes that its database is authoritative. This kind of issue was supposed to happen only when building from source, but in that case, ./configure tries hard to protect against that. Here it seems that the real issue is that ‘guix pull’ produces a ‘guix’ that does not honor your settings. Anyway, I hope you managed to recover from it without too much hassle. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#35874: “guix pull” fails on setlocale 2019-05-24 13:49 ` Ludovic Courtès @ 2019-05-24 14:11 ` Ricardo Wurmus 2019-05-25 17:17 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: Ricardo Wurmus @ 2019-05-24 14:11 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 35874 Ludovic Courtès <ludo@gnu.org> writes: >> When I started the daemon from “guix pull” without having set >> GUIX_DATABASE_DIRECTORY and I asked Guix to build something I noticed >> this error message: >> >> guix pull: error: cannot unlink `/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/gconv': Directory not empty > > When you do ‘guix pull’, the resulting (guix config) is supposed to > honor the settings of the calling ‘guix’: %localstatedir, etc. > > It seems that it wasn’t the case here? Could you try again running > ‘guix pull’ from a ‘guix’ command that has non-default settings and > check the resulting (guix config) module? Is (guix config) enough? What about the daemon? I’ve had no problem with “guix” itself when used with a daemon taken from the git checkout. >> Can we make the daemon detect that its understanding of the site differs >> from that of the Guix client? > > I don’t see how that could be done. The daemon necessarily assumes that > its database is authoritative. > > This kind of issue was supposed to happen only when building from > source, but in that case, ./configure tries hard to protect against > that. Here it seems that the real issue is that ‘guix pull’ produces a > ‘guix’ that does not honor your settings. This is confusing, because I *am* using the “guix” client from whatever “guix pull” produces. It’s just the daemon that works against me when I take it from the same directory as the “guix” client. So, “guix-daemon” currently runs from the git checkout, and all users talk to it with “guix” from various runs of “guix pull” (we initially pulled using the properly configured version from the git checkout). > Anyway, I hope you managed to recover from it without too much hassle. Yes, I was able to identify the corrupt store items and copy the corresponding items from a separate machine. I was lucky that it aborted early when trying to delete items, so it seems that it didn’t get to do all that much damage. (Curiously, I wasn’t able to run “guix gc --verify=repair,contents” because Guix claims I don’t have sufficient privileges to repair the store — I’m running this as root, but who knows how NFS complicates things…) -- Ricardo ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#35874: “guix pull” fails on setlocale 2019-05-24 14:11 ` Ricardo Wurmus @ 2019-05-25 17:17 ` Ludovic Courtès 2019-05-26 11:55 ` Ricardo Wurmus 0 siblings, 1 reply; 7+ messages in thread From: Ludovic Courtès @ 2019-05-25 17:17 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: 35874 [-- Attachment #1: Type: text/plain, Size: 2028 bytes --] Hi! Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis: > Ludovic Courtès <ludo@gnu.org> writes: [...] >> When you do ‘guix pull’, the resulting (guix config) is supposed to >> honor the settings of the calling ‘guix’: %localstatedir, etc. >> >> It seems that it wasn’t the case here? Could you try again running >> ‘guix pull’ from a ‘guix’ command that has non-default settings and >> check the resulting (guix config) module? > > Is (guix config) enough? What about the daemon? I’ve had no problem > with “guix” itself when used with a daemon taken from the git checkout. Oooh, good point, the ‘guix-daemon’ package uses a fixed localstatedir. I believe the patch below solves the problem. WDYT? > Yes, I was able to identify the corrupt store items and copy the > corresponding items from a separate machine. I was lucky that it > aborted early when trying to delete items, so it seems that it didn’t > get to do all that much damage. Phheeew. > (Curiously, I wasn’t able to run “guix gc --verify=repair,contents” > because Guix claims I don’t have sufficient privileges to repair the > store — I’m running this as root, but who knows how NFS complicates > things…) It’s supposed to work if you’re root, and the privilege claim checks just that (see nix-daemon.cc): --8<---------------cut here---------------start------------->8--- if (remoteAddr.ss_family == AF_UNIX) { […] trusted = clientUid == 0; […] case wopVerifyStore: { bool checkContents = readInt(from) != 0; bool repair = readInt(from) != 0; startWork(); if (repair && !trusted) throw Error("you are not privileged to repair paths"); bool errors = store->verifyStore(checkContents, repair); stopWork(); writeInt(errors, to); break; } --8<---------------cut here---------------end--------------->8--- Thanks, Ludo’. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 1212 bytes --] diff --git a/guix/self.scm b/guix/self.scm index 6d7569ec19..8cc82de64c 100644 --- a/guix/self.scm +++ b/guix/self.scm @@ -603,7 +603,21 @@ Info manual." (define (wrap daemon) (program-file "guix-daemon" #~(begin + ;; Refer to the right 'guix' command for 'guix + ;; substitute' & co. (setenv "GUIX" #$command) + + ;; Honor the user's settings rather than those hardcoded + ;; in the 'guix-daemon' package. + (unless (getenv "GUIX_STATE_DIRECTORY") + (setenv "GUIX_STATE_DIRECTORY" + #$(string-append %localstatedir "/guix"))) + (unless (getenv "GUIX_CONFIGURATION_DIRECTORY") + (setenv "GUIX_CONFIGURATION_DIRECTORY" + #$(string-append %sysconfdir "/guix"))) + (unless (getenv "NIX_STORE_DIR") + (setenv "NIX_STORE_DIR" %storedir)) + (apply execl #$(file-append daemon "/bin/guix-daemon") "guix-daemon" (cdr (command-line)))))) ^ permalink raw reply related [flat|nested] 7+ messages in thread
* bug#35874: “guix pull” fails on setlocale 2019-05-25 17:17 ` Ludovic Courtès @ 2019-05-26 11:55 ` Ricardo Wurmus 2019-05-26 21:24 ` Ludovic Courtès 0 siblings, 1 reply; 7+ messages in thread From: Ricardo Wurmus @ 2019-05-26 11:55 UTC (permalink / raw) To: Ludovic Courtès; +Cc: 35874 Hi Ludo, >>> When you do ‘guix pull’, the resulting (guix config) is supposed to >>> honor the settings of the calling ‘guix’: %localstatedir, etc. >>> >>> It seems that it wasn’t the case here? Could you try again running >>> ‘guix pull’ from a ‘guix’ command that has non-default settings and >>> check the resulting (guix config) module? >> >> Is (guix config) enough? What about the daemon? I’ve had no problem >> with “guix” itself when used with a daemon taken from the git checkout. > > Oooh, good point, the ‘guix-daemon’ package uses a fixed localstatedir. > > I believe the patch below solves the problem. WDYT? Yes, I think this would fix it. I set two of these variables before (not NIX_STORE_DIR) and it seemed to work fine. Thanks! -- Ricardo ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#35874: “guix pull” fails on setlocale 2019-05-26 11:55 ` Ricardo Wurmus @ 2019-05-26 21:24 ` Ludovic Courtès 0 siblings, 0 replies; 7+ messages in thread From: Ludovic Courtès @ 2019-05-26 21:24 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: 35874-done Hello! Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis: >> I believe the patch below solves the problem. WDYT? > > Yes, I think this would fix it. I set two of these variables before > (not NIX_STORE_DIR) and it seemed to work fine. Great. Pushed as dfc69e4b6d4bbc41a4d37b3cc6ea12adb34aaafa. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-05-26 21:25 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-05-23 21:01 bug#35874: “guix pull” fails on setlocale Ricardo Wurmus [not found] ` <handler.35874.B.155864531425074.ack@debbugs.gnu.org> 2019-05-23 21:40 ` Ricardo Wurmus 2019-05-24 13:49 ` Ludovic Courtès 2019-05-24 14:11 ` Ricardo Wurmus 2019-05-25 17:17 ` Ludovic Courtès 2019-05-26 11:55 ` Ricardo Wurmus 2019-05-26 21:24 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).