Re: having trouble modifying guix-daemon

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Robert Vollmert <rob@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’.