Hi, I’m trying to investigate why guix-daemon appears to spend a lot of time locking store directories. (It’s possible that it’s doing useful work and just the debug output is useless.)
To do this, I’ve tried adding some debug statements to the C++ files in guix/nix/…. I’m having trouble getting those changes live. My understanding is that committing those changes to my configured guix channel, then running $ guix pull should rebuild the guix client tools from that repository. That seems to work. Next, $ sudo guix system reconfigure should rebuild the system using that same repository, and thus pull in the updated guix daemon. That does not seem to be the case, not even after $ sudo herd restart guix-daemon Any hints? (Relatedly, two areas where it feels the Guix System feels needlessly confusing: - root guix vs. user guix (and apparently there’s even a system guix in /var/guix/profiles/system/profile/bin/guix: does that even get used? I’d be tempted to simplify this by going for a rootless setup (i.e., you can’t log in to root account, root has no home and no profile). Reasons against? - opaque system status: it’s very hard to figure out what configuration and what versions of programs are current. My current best attempt is to grep through the output of ps and then look at those paths in /gnu/store. This is made worse due to the lack of timestamps in /gnu/store, as I can’t tell which of the many versions of some package is the newest just from looking in /gnu/store. Then, the shepherd configuration is very opaque: I have to follow through a chain of illegible scheme modules to figure out what the current configuration is (and then how do I know I’m even looking at the right shepherd config?).) Robert
