Re: having trouble modifying guix-daemon

[Robert Vollmert]

Hi,

thanks for the detailed reply.

On 27. Jun 2019, at 17:34, Ludovic Courtès <address@hidden> wrote:
> Robert Vollmert <address@hidden> 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 …

Yes I found that, and the output is not very helpful (yet). I get hundreds
of repetitive

  acquiring write lock on `<dir>'
  downgrading to read lock on `<dir>'

at the start. By modifying that debug statement, I can now see that at least
these are calls to add roots for different parts — I assume by now that
these are client calls to add-temp-root.

I’d like to improve the debug output here more generally: At (high enough)
debug level, it seems to make sense to log every operation. What I’m unclear
on here is whether it’s better to do that client or server side, what do you
think? The spots would be

(a) nix/nix-daemon/nix-daemon.cc:performOp (inside each start/stopWork pair)
(b) guix/store.scm:operation (next to record-operation)

I have a slight preference for (b) since it avoids the sending data back
and forth.

>> 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

Thank you, that works!

>> (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.

Alright. I’ll see if I can figure out how to set up the system without
login-able root account, and might send a patch if successful.

>> - 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---
> 

That’s a bit more precise than what I was doing, thanks. It would be
quite helpful for `herd status` to do that work itself, what do you
think? Also maybe to optionally show the service definition?

(I do still think that having the system configuration stored in a
rather opaque database and only queryable via tools is a disadvantage.
Sort of like how systemd’s binary logging has disadvantages compared to
plain text logfiles in /var/log.)

> 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.

Thanks, interesting. Following the output of these commands, here are two
questions I didn’t manage to answer (1 would help answer 2):

1. Where is the current version and configuration of shepherd defined?
2. Which nginx version is part of the current system, with which configuration?

(One point where querying shepherd or guix about what’s current breaks down
is when debugging the system. It’s really helpful to have some redundancy
there, where I can compare the input, some files, and what guix/shepherd
think to see which is at odds. That’s not necessarily debugging the system
btw, might also be debugging my understanding. :) )

> 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.

Couldn’t `guix system status` even be useful without the config.scm argument?
Showing the kernel that’s part of the system configuration compared to the
running kernel, and services that are part of the system configuration compared
to what’s running.

Robert