Subject: bug#77220: closed (Re: bug#77220: [shepherd]: Timers do not set HOME environment variable correctly)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 26 Mar 2025 22:12:02 +0000

Your bug report

#77220: [shepherd]: Timers do not set HOME environment variable correctly

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
77220: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77220
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#77220: [shepherd]: Timers do not set HOME environment variable correctly
From: Tomas Volf <[email-masked]>
To: Ludovic Courtès <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Mar 2025 23:11:06 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Ludovic Courtès <[email-masked]> writes:

> Hi Tomas,
>
> Tomas Volf <[email-masked]> skribis:
>
>> Given a timer executed under some user (via #:user "git" #:group "git"
>> keyword arguments), the HOME variable is set to /.  Is that correct?  I
>> get that it might be desirable for a root user, but for regular users
>> that is surprising and causes (for example gitolite from the package of
>> the same name) to not function:
>>
>>   2025-03-23 21:09:06 FATAL: errors found but logfile could not be created
>>   2025-03-23 21:09:06 FATAL: //.gitolite/logs/gitolite-2025-03.log: No such file or directory
>>   2025-03-23 21:09:06 FATAL: die	chdir //.gitolite failed: No such file or directory<<newline>>
>>
>> 1. Is this intentional?
>> 2. If yes, is this something you would be opened to changing?
>
> Timers do not set ‘HOME’ (or any other environment variable) at all.
> That is, they take what’s given in (command … #:environment-variables …)
> and don’t touch it.
>
> It’s intentional, but the downside is that it can lead to more verbose
> timer definitions, where would have to explicitly do:
>
>   (command … #:environment-variables
>              (cons "HOME=/whatever" (default-environment-variables)))
>
> or similar.
>
> How does that sound?

It sounds... verbose. :)  In practice it cannot be

--8<---------------cut here---------------start------------->8---
(command … #:environment-variables
           (cons "HOME=/whatever" (default-environment-variables)))
--8<---------------cut here---------------end--------------->8---

but something like

--8<---------------cut here---------------start------------->8---
(command … #:environment-variables
           (cons (string-append "HOME="
                                (passwd:dir (getpwnam "whatever")))
                 (default-environment-variables)))
--8<---------------cut here---------------end--------------->8---

I do however see your point, I simply need to get the timer == cron
approximation out of my head.  I am viewing it too much through "this is
cron" lenses.  I just add this (setting the home) into my wrapper.

I am closing this bug, since there is nothing to do here.

Thanks for the explanation,
Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Subject: [shepherd]: Timers do not set HOME environment variable correctly
From: Tomas Volf <[email-masked]>
To: [email-masked]
Date: Sun, 23 Mar 2025 22:29:48 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

I am in a process of porting my crontabs over to shepherd timers and
noticed a difference.

Given a timer executed under some user (via #:user "git" #:group "git"
keyword arguments), the HOME variable is set to /.  Is that correct?  I
get that it might be desirable for a root user, but for regular users
that is surprising and causes (for example gitolite from the package of
the same name) to not function:

--8<---------------cut here---------------start------------->8---
  2025-03-23 21:09:06 FATAL: errors found but logfile could not be created
  2025-03-23 21:09:06 FATAL: //.gitolite/logs/gitolite-2025-03.log: No such file or directory
  2025-03-23 21:09:06 FATAL: die	chdir //.gitolite failed: No such file or directory<<newline>>
--8<---------------cut here---------------end--------------->8---

1. Is this intentional?
2. If yes, is this something you would be opened to changing?

Or at least, if this is intentional, would it not be better to not set
HOME at all instead of to a wrong value?

For the time being, I will just do `HOME=~git' as a first line of all
the scripts, but it is not great having to do that everywhere.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.