GNU bug report logs - #77288
[PATCH 0/6] Rootless guix-daemon on Guix System

Previous Next

Full log

Message #145 received at 77288 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 77288 <at> debbugs.gnu.org
Subject: Re: [bug#77288] [PATCH v2 7/8] services: guix: Allow
 ‘guix-daemon’
 to run without root privileges.
Date: Tue, 22 Apr 2025 10:07:47 +0900

Hi Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hello,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>>> This procedure emulates lchown(2), for which Guile does not provide
>>> bindings.
>>
>> OK.  Perhaps it should?  We could report to bug-guile and here add a
>> comment pointing to the issue to remind us to export it in Guile and use
>> it when it's there in the future.
>
> Yes, we should do that.

OK, done; see bug#77977.

>>>> Likewise.  Also, I never remember why `in-vicinity' is useful, and it's
>>>> not documented anywhere.
>>>
>>> It.s more concise and more accurate than (string-append a "/" b).
>>> I.ve come to use it more.
>>
>> It's problematic that it's not documented though.  Grepping the guile
>> source shouldn't be needed to understand the code, ideally.  The
>> 'in-vicinity' name also suggests it might do something cleverer than
>> just concatenating strings.
>
> It’s “clever” in that it appends a slash only if needed.  That’s the
> extent of its cleverness :-) but it’s nice.

OK, I've created another issue to have that documented in Guile, see
bug#77978.

>>> C.UTF-8 is now always available (embedded in our libc), but the default
>>> is always C.
>>
>> Uh.  Are there plans to change this in the future?  It seems we're well
>> into the Unicode age :-).
>
> It’s a POSIX issue though: processes always start out under the C locale
> and have to call setlocale(3) to change that.

Maybe we can in some places, like GNU advises, choose a slightly
different path than POSIX, where it improves the life of our users.
Patch bug#71262 from Tomas appears to take that route.

[...]

> Waiting for ‘start-service’ to complete guarantees that the attempt to
> start the service has completed, and checking its return value lets you
> know whether it has succeeded.
>
> Here’s an example with my user shepherd, where ‘redshift’ was already
> running and ‘failing’ was stopped but its ‘start’ method is (const #f):
>
> scheme@(gnu services herd)> (parameterize ((%shepherd-socket-file "/run/user/1000/shepherd/socket")) (start-service 'redshift))
> shepherd: Service redshift is already running.
> $7 = (service (version 0) (provides (redshift)) (requires (x11-display)) (respawn? #t) (docstring "Redshift program.") (enabled? #t) (running (process (version 0) (id 2691) (command ("/gnu/store/arj5gvqdi3j9kbpk9vjdh5l0gk1gaqsh-redshift-1.12/bin/redshift" "-c" "/gnu/store/lj6ajc15a3i7q198hb69gsda8dcxzh6f-redshift.conf")))) (conflicts ()) (last-respawns ()) (status-changes (…)) (startup-failures ()) (status running) (one-shot? #f) (transient? #f) (respawn-limit (5 . 7)) (respawn-delay 0.1) (actions (configuration)) (exit-statuses ((0 . 1745228665) …)) (recent-messages ((1745228689 . "Location: …") (1745228689 . "Waiting for initial location to become available..."))) (log-files ()) (pending-replacement? #f))
> scheme@(gnu services herd)> (parameterize ((%shepherd-socket-file "/run/user/1000/shepherd/socket")) (start-service 'failing))
> shepherd: Starting service failing...
> shepherd: Service failing failed to start.
> shepherd: Service failing could not be started.
> $8 = #f
>
> If we get the full-blown service sexp, as in the ‘redshift’ example, it
> means that the service is ‘started’.

Thanks for the demonstration, it does indeed look like it works as
expected/used.

Maybe the last thing that could go wrong is if there's a syntax error in
the start slot and shepherd is not even able to run it, but then
something much worst would likely happen (like the system failing to
boot).  If I again encounter a problem with it, I'll make sure to keep
notes/the exact context in which it happened.

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.