Hi, Robert Vollmert <r...@vllmrt.net> skribis:
> 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.) Note that there are already quite a few debugging statements that you can view by running something like: guix build --debug=5 … > 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. Unfortunately no. The ‘guix’ channel is built using (guix self). That module has code to build everything, except the daemon itself; for the daemon, it resorts to the ‘guix-daemon’ package of (gnu packages package-management). Thus, changes to the C++ code base do not propagate until we update the ‘guix’ and thus the ‘guix-daemon’ package. It’s usually not a problem, but it does mean that your use case is not supported. I would suggest simply building it from a checkout and running it directly from there: sudo herd stop guix-daemon sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild > (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? No, that’s actually what we recommend now—that is, not running ‘guix pull’ as root. > - 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?).) Are you talking about the status of system services specifically? For those, my trick is usually to simply look up the command line of the service, like so: --8<---------------cut here---------------start------------->8--- $ sudo herd status ssh-daemon Status of ssh-daemon: It is started. Running value is 528. It is enabled. Provides (ssh-daemon). Requires (syslogd loopback). Conflicts with (). Will be respawned. $ sudo cat /proc/528/cmdline |xargs -0 echo /gnu/store/qpvxwh0l5l2vs7m6dnaclb5y5vll0mlg-openssh-8.0p1/sbin/sshd -D -f /gnu/store/0h0lap06j58acndz9agdzf10cj1gqnr8-sshd_config --8<---------------cut here---------------end--------------->8--- For the global profile, you can of course just run: guix package -p /run/current-system/profile -I There’s also ‘guix system list-generations’, which prints useful info. Last, there’s a trick to embed the OS config file directly in /run/current-system, for those who want it. That said, we could have a command like: guix system status /etc/config.scm It would print, for the kernel, profile, and services, which are current and which differ. It usually won’t be able to tell much beyond that one bit: current or not. Thoughts? Ludo’.
