Re: having trouble modifying guix-daemon

[Ludovic Courtès]

Hello,

Robert Vollmert <address@hidden> skribis:

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

In my experience I rarely need to log every operation (e.g., every RPC),
and when I do, I add a well-placed ‘pk’.  :-)  If you have a specific
example in mind, we can discuss it, but my feeling is that it’s often
better to just go ahead and add the debugging statement that precisely
shows what you want rather than add “generic” debugging statements.

Also, there’s GUIX_PROFILING for general statistics; that is pretty
useful IMO.

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

The problem is that, with its current API, the Shepherd doesn’t see
processes with a command; it just sees <service> classes with a ‘start’
method.

That said, when the “running value” is a number, it’s must be a PID; so
in this case, ‘herd status’ could definitely write the output of
/proc/PID/cmdline for you.  Would you like to give it a try?

The service definition cannot really be shown, at least not in a
meaningful way, but it could show source location information, which
would already be an improvement.  We just need to add a ‘location’ field
to <service>, I guess.

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

I see what you mean, but I also think is a matter of perspective: after
all, Guix allows you to view your OS config as a regular object in
Scheme, you can traverse it to view its services, etc.  This expressive
power can hardly be achieved at the command line.

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

cat /proc/1/cmdline :-)

> 2. Which nginx version is part of the current system, with which 
> configuration?

You can do things like:

  guix gc -R $(readlink -f /run/current-system) | grep nginx

or again ‘herd status nginx’ as discussed before.

I agree that we should work on better UIs here.

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

That would compare /run/booted-system to /run/current-system, right?
That could work, I guess.

Thanks,
Ludo’.