From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Vollmert Subject: Re: having trouble modifying guix-daemon Date: Fri, 28 Jun 2019 09:19:01 +0200 Message-ID: <28B65776-E327-4540-B5DA-A9B6F5C34BEC@vllmrt.net> References: <871rzfxcs4.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47016) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hglAA-0005aG-Aa for guix-devel@gnu.org; Fri, 28 Jun 2019 03:19:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hglA8-0000N9-Ot for guix-devel@gnu.org; Fri, 28 Jun 2019 03:19:14 -0400 In-Reply-To: <871rzfxcs4.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: =?utf-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel@gnu.org Hi, thanks for the detailed reply. On 27. Jun 2019, at 17:34, Ludovic Court=C3=A8s wrote: > Robert Vollmert skribis: >=20 >> I=E2=80=99m trying to investigate why guix-daemon appears to spend >> a lot of time locking store directories. (It=E2=80=99s possible that >> it=E2=80=99s doing useful work and just the debug output is useless.) >=20 > Note that there are already quite a few debugging statements that you > can view by running something like: >=20 > guix build --debug=3D5 =E2=80=A6 Yes I found that, and the output is not very helpful (yet). I get = hundreds of repetitive acquiring write lock on `' downgrading to read lock on `' at the start. By modifying that debug statement, I can now see that at = least these are calls to add roots for different parts =E2=80=94 I assume by = now that these are client calls to add-temp-root. I=E2=80=99d 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=E2=80=99= m unclear on here is whether it=E2=80=99s 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=E2=80=99ve tried adding some debug statements to the >> C++ files in guix/nix/=E2=80=A6. I=E2=80=99m having trouble getting = those >> changes live. My understanding is that committing those >> changes to my configured guix channel, then running >>=20 >> $ guix pull >>=20 >> should rebuild the guix client tools from that repository. >=20 > Unfortunately no. The =E2=80=98guix=E2=80=99 channel is built using = (guix self). That > module has code to build everything, except the daemon itself; for the > daemon, it resorts to the =E2=80=98guix-daemon=E2=80=99 package of = (gnu packages > package-management). Thus, changes to the C++ code base do not > propagate until we update the =E2=80=98guix=E2=80=99 and thus the = =E2=80=98guix-daemon=E2=80=99 package. >=20 > It=E2=80=99s usually not a problem, but it does mean that your use = case is not > supported. >=20 > I would suggest simply building it from a checkout and running it > directly from there: >=20 > sudo herd stop guix-daemon > sudo -E ./pre-inst-env guix-daemon --build-users-group=3Dguixbuild Thank you, that works! >> (Relatedly, two areas where it feels the Guix System feels >> needlessly confusing: >> - root guix vs. user guix (and apparently there=E2=80=99s even a >> system guix in /var/guix/profiles/system/profile/bin/guix: >> does that even get used? >> I=E2=80=99d be tempted to simplify this by going for a rootless >> setup (i.e., you can=E2=80=99t log in to root account, root has no >> home and no profile). Reasons against? >=20 > No, that=E2=80=99s actually what we recommend now=E2=80=94that is, not = running =E2=80=98guix > pull=E2=80=99 as root. Alright. I=E2=80=99ll 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=E2=80=99s 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=E2=80=99t 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=E2=80=99m even looking at the right shepherd config?).) >=20 > 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: >=20 > --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--- >=20 That=E2=80=99s 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=E2=80=99s binary logging has disadvantages = compared to plain text logfiles in /var/log.) > For the global profile, you can of course just run: >=20 > guix package -p /run/current-system/profile -I >=20 > There=E2=80=99s also =E2=80=98guix system list-generations=E2=80=99, = which prints useful info. Thanks, interesting. Following the output of these commands, here are = two questions I didn=E2=80=99t 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=E2=80=99s current = breaks down is when debugging the system. It=E2=80=99s 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=E2=80=99s not necessarily debugging = the system btw, might also be debugging my understanding. :) ) > Last, there=E2=80=99s a trick to embed the OS config file directly in > /run/current-system, for those who want it. >=20 > That said, we could have a command like: >=20 > guix system status /etc/config.scm >=20 > It would print, for the kernel, profile, and services, which are = current > and which differ. It usually won=E2=80=99t be able to tell much = beyond that one > bit: current or not. Couldn=E2=80=99t `guix system status` even be useful without the = config.scm argument? Showing the kernel that=E2=80=99s part of the system configuration = compared to the running kernel, and services that are part of the system configuration = compared to what=E2=80=99s running. Robert