bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

[nils]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

Hello,
 
when using the home-mcron-service, PATH is set to /run/current-system/profile/bin . This directory is empty when using guix home on a foreign distro, meaning all executable paths would need to be absolute. This includes stuff like /usr/bin/ssh, /usr/bin/nice etc..
 
My guess for the culprit was 1c30d5a6bfc5d48137f4bdcc271189a06fdc6ed3 , which replaced the custom home-mcron-service-type with mapping it to mcron-service-type. 
The mcron shepherd service in old service type did not mess with the environment variables, the inherited one does:
#:environment-variables
(cons* "GUILE_AUTO_COMPILE=0"
"PATH=/run/current-system/profile/bin"
(remove (cut string-prefix? "PATH=" <>)
(environ)))
 
Strange thing is that the commit is from 2023-08-06, and I update guix almost every day, but did not run into the issue until today. But the commit seems to fit the issue perfectly, so I'm not sure what's going on at all.

[-- Attachment #2: Type: text/html, Size: 1454 bytes --]

bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

[Ludovic Courtès]

Hi,

Apologies for the delay.

nils@landt.email skribis:

> when using the home-mcron-service, PATH is set to /run/current-system/profile/bin . This directory is empty when using guix home on a foreign distro, meaning all executable paths would need to be absolute. This includes stuff like /usr/bin/ssh, /usr/bin/nice etc..
>  
> My guess for the culprit was 1c30d5a6bfc5d48137f4bdcc271189a06fdc6ed3 , which replaced the custom home-mcron-service-type with mapping it to mcron-service-type. 
> The mcron shepherd service in old service type did not mess with the environment variables, the inherited one does:
> #:environment-variables
> (cons* "GUILE_AUTO_COMPILE=0"
> "PATH=/run/current-system/profile/bin"
> (remove (cut string-prefix? "PATH=" <>)
> (environ)))

As a rule of thumb, I personally always provide absolute file names, as
in #~(job … #$(file-append coreutils "/bin/ls") …).

I wonder what the preferred behavior would be.  Restore PATH to whatever
value it had when the user ‘shepherd’ process was started, at the
expense of making things harder to track/less reproducible?  Should we
leave it unset, possibly breaking programs that expect it to be set?
Should we set it to “/run/current-system/profile/bin:/usr/bin” or
similar?

Thanks,
Ludo’.

bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

[Oleg Pykhalov]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:
[…]

> I wonder what the preferred behavior would be.  Restore PATH to whatever
> value it had when the user ‘shepherd’ process was started, at the
> expense of making things harder to track/less reproducible?  Should we
> leave it unset, possibly breaking programs that expect it to be set?
> Should we set it to “/run/current-system/profile/bin:/usr/bin” or
> similar?

1c30d5a6 was almost 3 months ago, so we could assume most of the users
are already reconfigured to this (or newer) commit and fixed their
configurations accordingly.

Because we probably cannot be sure how they fixed it, I think the best
that we could do is not to change the current behavior again and provide
a support and documentation if needed, so we don't break users
configurations again.

Also, the current behavior ‘PATH=/run/current-system/profile/bin’
matches with mcron started by Shepherd on a Guix System on pretty recent
commit ‘fc6bdaad57bf91609849623c5f485403c030cb49’, which probably is
better than difference of PATH dependending on is it system's Shepherd
or user's Shepherd instance running.

We could allow users to control an environment of mcron, but I think it
should be:

- optional for both system's and user's Shepherd instances;
- not a default behavior, because we already switched from PATH=<IMPURE>
  to ‘PATH=/run/current-system/profile/bin’.


Regards,
Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

[Nils Landt]

> Ludovic Courtès <ludo@gnu.org> hat am 20.11.2023 23:10 CET geschrieben:

> nils@landt.email skribis:
> 
> > when using the home-mcron-service, PATH is set to /run/current-system/profile/bin . This directory is empty when using guix home on a foreign distro, meaning all executable paths would need to be absolute. This includes stuff like /usr/bin/ssh, /usr/bin/nice etc..
> >  
> > My guess for the culprit was 1c30d5a6bfc5d48137f4bdcc271189a06fdc6ed3 , which replaced the custom home-mcron-service-type with mapping it to mcron-service-type. 
> > The mcron shepherd service in old service type did not mess with the environment variables, the inherited one does:
> > #:environment-variables
> > (cons* "GUILE_AUTO_COMPILE=0"
> > "PATH=/run/current-system/profile/bin"
> > (remove (cut string-prefix? "PATH=" <>)
> > (environ)))
> 
> As a rule of thumb, I personally always provide absolute file names, as
> in #~(job … #$(file-append coreutils "/bin/ls") …).

I do the same, but occasionally a program I call expects something to be available in PATH. For me (guix home in Debian 12), this includes Guix itself.
Running 
/home/nl/.config/guix/current/bin/guix pull 
in a terminal works perfectly fine, but
unset PATH
/home/nl/.config/guix/current/bin/guix pull 
results in a stacktrace that ends in:
In guix/scripts/pull.scm:
    453:4  4 (_)
In guix/build/utils.scm:
    625:6  3 (which "guix")
In unknown file:
           2 (string-tokenize #f #<charset {#\nul..#\9 #\;..#\15377…> …)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure string-tokenize: Wrong type argument in position 1 (expecting string): #f

> I wonder what the preferred behavior would be.  Restore PATH to whatever
> value it had when the user ‘shepherd’ process was started, at the
> expense of making things harder to track/less reproducible?  Should we
> leave it unset, possibly breaking programs that expect it to be set?
> Should we set it to “/run/current-system/profile/bin:/usr/bin” or
> similar?

I think the previous behaviour was fine for a user level service. I'm guessing this was inheriting the environment variables from the shepherd process that started mcron?

Otherwise, adding /usr/local/bin:/usr/bin:/bin should be a good default I think.

I'm not emotionally invested either way, I have moved away from shepherd / mcron.