home mcron service overwrites PATH with a GuixSD-only directory

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.

Hi,

Apologies for the delay.

nils@landt.email skribis:

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’.

Hi Ludovic,

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

[…]

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.

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 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.

Hi,

I've just experienced the problem first hand:

Nils suggested to set the `PATH` environment variable, but 1) I have no

clue how to do that ? and 2) it is not exactly the behaviour I would

expect from a home service.

Has anything been decided?

Regards,

--

Tanguy

Hi Guix,

The bug in which home-mcron-service-type overwrites the user's PATH with a single non-existent directory makes mcron completely unusable on foreign distros. Since it seems to me that foreign distros are the main target for home mcron services (since there is no global shepherd to run mcron for you), this really should be elevated to a high priority bug.

I see that earlier in this message thread questions were raised as to what the proper behavior should be for setting the PATH, but I think we can say with no reservations that setting PATH to a directory that is guaranteed not to exist on a foreign distro is definitely not the correct choice. Also, setting it explicitly to directories not managed by Guix profiles or Guix Home like /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, and so on also isn't a great idea since users of the home-cron-service-type are obviously using it through Guix Home. The correct choice IMHO is to follow the principle of least surprise here.

Namely, in the Guix info pages at "(guix)Top > Home Configuration > Home Services > Mcron Home Service", we have section "13.3.3 Scheduled User’s Job Execution". Under home-mcron-configuration, we see the "jobs" field, which links us to "mcron job specifications(mcron)" for explanations of how to define our mcron jobs.

Following this link on to "(mcron)Top > Syntax > Guile Syntax", we encounter section "3.1.1 Job specification". The final paragraph in this section reads as follows:

Note the third sentence:

"If a string is passed, it is assumed to be shell script and is executed with the user's default shell."

Reading that, I (and I imagine most mcron users) will infer that the environment my job command will run in will be the same as what I would get if I spawned a new non-interactive shell. That is, the new mcron job shell should inherit all the environment variables that were defined when the user's sheperd process was launched (which will be everything loaded into a standard login shell, such as /etc/profile, ~/.bash_profile, and everything that they source like Guix Home's ~/.profile) plus a fresh run of ~/.bashrc (or the equivalent non-interactive shell config file for whatever shell the user has chosen). It seems to me that this is what most people reading the manual are going to understand (and therefore expect) and that it is the most compatible with Guix Home since all environment variables set in the `home-environment` will be available to our mcron jobs.

However, with the current behavior, it appears that the shell spawned for the user mcron job actually reads /etc/profile and ~/.profile (but not ~/.bash_profile or ~/.bashrc). The ~/.profile file sources ~/.guix-home/setup-environment and then runs ~/.guix-home/on-first-login. While being very confusing and unintuitive (because my default shell is /bin/bash and is reported correctly within the mcron job environment as "SHELL=/bin/bash"), this at least loads ~/.guix-home/profile/etc/profile and ~/.guix-profile/etc/profile. However, since mcron then promptly erases the correctly built up PATH from Guix Home and the user's main Guix profile, the commands executed in this PATH-less shell are borked.

As others in this thread have previously noted, with the current behavior of providing an unintuitive and completely unusable PATH to user mcron jobs, the home-mcron-service-type is largely unusable except for the simplest commands in which you can use ungexp package directory expansion to build up the locations of a Guix-installed executable. However, if any job command ever needs to shell out to any other executable, it will not be found, and the job will crash and burn.

Please fix this, folks. And if you aren't willing to implement the intuitive, documented, and Guix Home compatible shell behavior described above, please at the very least extend the "job" function with a keyword to allow us to pass environment variables into the mcron job shell along with something like the "(default-environment-variables)" function that is available for shepherd service "start" functions.

Thanks!

Gary

--

GPG Key ID: C4FBEDBD

Use `gpg --search-keys tracker@disroot.org' to find me

Protect yourself from surveillance: https://emailselfdefense.fsf.org

=======================================================================

() ascii ribbon campaign - against html e-mail

/\ www.asciiribbon.org - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.

See http://www.gnu.org/philosophy/no-word-attachments.html