[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60106: closed ([Shepherd 0.9.3] ‘system*’ replacement cannot be pass

From: GNU bug Tracking System
Subject: bug#60106: closed ([Shepherd 0.9.3] ‘system*’ replacement cannot be passed environment variables)
Date: Sat, 04 Mar 2023 22:11:02 +0000

Your message dated Sat, 04 Mar 2023 23:09:49 +0100
with message-id <877cvwp3rm.fsf@gnu.org>
and subject line Re: bug#61803: [PATCH 0/3] [shepherd] improve race-free 
has caused the debbugs.gnu.org bug report #60106,
regarding [Shepherd 0.9.3] ‘system*’ replacement cannot be passed environment 
to be marked as done.

(If you believe you have received this mail in error, please contact

60106: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60106
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: [Shepherd 0.9.3] ‘system*’ replacement cannot be passed environment variables Date: Thu, 15 Dec 2022 23:47:15 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
As we found out while debugging <https://issues.guix.gnu.org/60010>, the
Shepherd 0.9.3, with its ‘system*’ replacement (aka. ‘spawn-command’),
makes it very hard to spawn a command with different environment

The following options don’t work:

  • Changing shepherd’s own environment variables with ‘setenv’ for
    instance: ‘spawn-command’ calls ‘fork+exec-command’, whose default
    #:environment-variables is provided by the
    ‘default-environment-variables’ parameter, which gets its default
    value at when shepherd starts.  There’s no environment variable
    inheritance, contrary to the real ‘system*’.

  • Parameterizing ‘default-environment-variables’:

       (parameterize ((default-environment-variables …))
         (system* …))

    That won’t work because ‘spawn-command’ delegates to the process
    monitoring fiber, which has a different dynamic state and thus
    doesn’t see this change.

  • Even a plain (set! default-environment-variables …) won’t work,
    probably due to inlining within (shepherd services).

I think we’ll have to add a parameter to ‘spawn-command’ to specify
environment variables.


--- End Message ---
--- Begin Message --- Subject: Re: bug#61803: [PATCH 0/3] [shepherd] improve race-free spawn+wait Date: Sat, 04 Mar 2023 23:09:49 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Hi Ulf,

Ulf Herrman <striness@tilde.club> skribis:

> From 51ee63ace6f3f52eb196c990664cc6b9af3d3683 Mon Sep 17 00:00:00 2001
> From: ulfvonbelow <striness@tilde.club>
> Date: Sat, 25 Feb 2023 00:46:27 -0600
> Subject: [PATCH 2/3] service: accept fork+exec-command argument list in
>  monitor.
> Sometimes it's necessary to run startup / shutdown programs as a certain user,
> in a certain directory, with certain environment variables, etc.  Shepherd
> currently provides a replacement for system* that won't race against the
> child process auto-reaper, but this lacks the flexibility Shepherd users are
> used to.
> * modules/shepherd/service.scm (process-monitor): treat command instead as
>   argument list to fork+exec-command.
>   (spawn-via-monitor): update to new convention.
>   (fork+exec+wait-command): new procedure.

On this one I took a similar approach but chose to extend
‘spawn-command’ instead of introducing a new procedure—see commit

Another difference is explicitly listing keyword arguments so that their
default values are taken from the caller’s dynamic state and not from
that of the process monitoring fiber.  This fixes

Let me know what you think!


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]