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.