GNU logs - #78355, boring messages

Message sent to ludo@HIDDEN, bug-guix@HIDDEN:

Subject: bug#78355: guix-ownership inconsistent state
Resent-From: Rutherther <rutherther@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: ludo@HIDDEN, bug-guix@HIDDEN
Resent-Date: Sat, 10 May 2025 15:35:01 +0000
Resent-Message-ID: <handler.78355.B.1746891263371 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 78355 <at> debbugs.gnu.org
Cc: ludo@HIDDEN
From: Rutherther <rutherther@HIDDEN>
Date: Sat, 10 May 2025 17:33:56 +0200
Message-ID: <87tt5sjx97.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2a01:4f8:1c1b:6a1c::;
 envelope-from=rutherther@HIDDEN; helo=mail.ditigal.xyz
X-Spam_score_int: 4
X-Spam_score: 0.4
X-Spam_bar: /
X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499,
 FROM_SUSPICIOUS_NTLD_FP=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 3.4 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: There are reports from users with inconsistencies in
 ownership, 
 it seems that at least /var/guix is sometimes left with wrong owner, but
 maybe even parts of the store? I cannot verify that. The guix-ownership
 service
 checks /gnu/store ownership to check if the whole store and all files
 important
 for the daemon (/etc/guix, /var/guix) are owned by the appropriate user. 
 Content analysis details:   (3.4 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: ditigal.xyz (xyz)]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
 id=rutherther%40ditigal.xyz; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
 0.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  There are reports from users with inconsistencies in ownership,
    it seems that at least /var/guix is sometimes left with wrong owner, but
   maybe even parts of the store? I cannot verify that. The guix-ownership service
    checks /gnu/store ownership to check if the whole store and all files important
    for the daemon (/etc/guix, /var/guix) are owned by the appropriate user. 
 
 Content analysis details:   (2.4 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [2001:470:142:0:0:0:0:17 listed in]
                             [list.dnswl.org]
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
  0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=rutherther%40ditigal.xyz;ip=2001%3A470%3A142%3A%3A17;r=debbugs.gnu.org]
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager


There are reports from users with inconsistencies in ownership, it seems that at
least /var/guix is sometimes left with wrong owner, but maybe even parts
of the store? I cannot verify that.

The guix-ownership service checks /gnu/store ownership to check if the
whole store and all files important for the daemon (/etc/guix,
/var/guix) are owned by the appropriate user.

If the folder isn't owned by appropriate user, it moves to those steps:
1. Fix permissions in /gnu/store - first under it, then /gnu/store
itself as last step
2. Fix /var/guix
3. Fix /etc/guix
4. Fix /var/log/guix

So from those laid out steps it should be obvious that if guix-ownership
service somehow stops between steps 1 and 2, it will never recover
ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
change owner as last.

On the other hand it feels much of a coincidence users would be
consistently hitting reboots between those steps. So maybe I am
overlooking another thing. I checked the file-system-fold, it goes to
/gnu/store as last, so that would mean putting step 1 after 4 should fix
that. Still, maybe only /gnu/store itself should be skipped instead of moving
the step, and done as last, step 5 to ensure it's fine even if
file-system-fold somehow changed the ordering? Not sure how exactly it
should behave in that regard.

Regards
Rutherther

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Rutherther <rutherther@HIDDEN>
Subject: bug#78355: Acknowledgement (guix-ownership inconsistent state)
Message-ID: <handler.78355.B.1746891263371.ack <at> debbugs.gnu.org>
References: <87tt5sjx97.fsf@HIDDEN>
X-Gnu-PR-Message: ack 78355
X-Gnu-PR-Package: guix
Reply-To: 78355 <at> debbugs.gnu.org
Date: Sat, 10 May 2025 15:35:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  ludo@HIDDEN
(after having been given a bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 78355 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
78355: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78355
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#78355: guix-ownership inconsistent state
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 14 May 2025 21:52:05 +0000
Resent-Message-ID: <handler.78355.B78355.174725949922315 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Rutherther <rutherther@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <87tt5sjx97.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Sat, 10 May 2025 17:33:56 +0200")
References: <87tt5sjx97.fsf@HIDDEN>
Date: Wed, 14 May 2025 22:33:09 +0200
Message-ID: <874ixnyltm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi,

Rutherther <rutherther@HIDDEN> writes:

> There are reports from users with inconsistencies in ownership, it seems =
that at
> least /var/guix is sometimes left with wrong owner, but maybe even parts
> of the store? I cannot verify that.

Would be nice to get their reports here, otherwise we=E2=80=99re left
speculating.

> The guix-ownership service checks /gnu/store ownership to check if the
> whole store and all files important for the daemon (/etc/guix,
> /var/guix) are owned by the appropriate user.
>
> If the folder isn't owned by appropriate user, it moves to those steps:
> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
> itself as last step
> 2. Fix /var/guix
> 3. Fix /etc/guix
> 4. Fix /var/log/guix
>
> So from those laid out steps it should be obvious that if guix-ownership
> service somehow stops between steps 1 and 2, it will never recover
> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
> change owner as last.

Well, the fundamental assumption is that =E2=80=98guix-ownership=E2=80=99 i=
s not
interrupted during its work; manual intervention is needed to repair
things if it is interrupted.

I don=E2=80=99t see any way around that but perhaps we should warn about it=
 more
clearly?

> On the other hand it feels much of a coincidence users would be
> consistently hitting reboots between those steps. So maybe I am
> overlooking another thing. I checked the file-system-fold, it goes to
> /gnu/store as last, so that would mean putting step 1 after 4 should fix
> that. Still, maybe only /gnu/store itself should be skipped instead of mo=
ving
> the step, and done as last, step 5 to ensure it's fine even if
> file-system-fold somehow changed the ordering? Not sure how exactly it
> should behave in that regard.

Doing /gnu/store last is a good idea because it reduces the window
during which the inconsistent state could go undetected.

Feel free to propose a patch; otherwise I=E2=80=99ll give it a try, but not
before next week.

Thanks,
Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

Subject: bug#78355: guix-ownership inconsistent state
Resent-From: Rutherther <rutherther@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 May 2025 07:37:02 +0000
Resent-Message-ID: <handler.78355.B78355.174729456810686 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org, Ben Sturmfels <ben@HIDDEN>
From: Rutherther <rutherther@HIDDEN>
In-Reply-To: <874ixnyltm.fsf@HIDDEN>
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
Date: Thu, 15 May 2025 09:35:52 +0200
Message-ID: <87msbeuy07.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
 
 Content preview:  Hi Ben, I am CCing you to get more information about the inconsistent
    ownership, if you could help with that. The most important questions are
   probably: 0. Are you sure the service actually ran after you reconfigured
   to root? It should definitely run after reboot, not sure if after reconfigure
    as the service [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
                             The query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              for more information.
                             [78.46.201.50 listed in sa-accredit.habeas.com]
  0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
                             query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              for more information.
                             [78.46.201.50 listed in bl.score.senderscore.com]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager


Hi Ben,

I am CCing you to get more information about the inconsistent ownership,
if you could help with that.

The most important questions are probably:
0. Are you sure the service actually ran after you reconfigured to root?
  It should definitely run after reboot, not sure if after reconfigure
  as the service already exists, it's just modified
1. Do you think you could've killed the service when it was running
after you reconfigured back to privileged daemon, ie. by rebooting when
it was running?
2. Do you know what folders had wrong owners?
  - Was everything under /var/guix fully owned by 971?
  - Was everything under /etc/guix fully owned by 971?
  - Was everything under store fully owned by 971?

Hi Ludo,

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> Hi,
>
> Rutherther <rutherther@HIDDEN> writes:
>
>> There are reports from users with inconsistencies in ownership, it seems=
 that at
>> least /var/guix is sometimes left with wrong owner, but maybe even parts
>> of the store? I cannot verify that.
>
> Would be nice to get their reports here, otherwise we=E2=80=99re left
> speculating.

I am afraid we will be left speculating either way, that's why I chose
this approach. That is because none of the users I know of took time to
debug it and just fixed it. CCing Ben Sturmfels who
encountered it (see
https://lists.gnu.org/archive/html/help-guix/2025-05/msg00052.html).
For the other user I know of, I don't know their e-mail.

Note that on IRC I recommended the user to chown $USER /gnu/store
($USER just cause it's easiest, any non-root user would be fine) and
herd start guix-ownership and that fixed the issue. So the service
definitely is doing its job. See here https://logs.guix.gnu.org/guix/2025-0=
5-10.log#171215

>
>> The guix-ownership service checks /gnu/store ownership to check if the
>> whole store and all files important for the daemon (/etc/guix,
>> /var/guix) are owned by the appropriate user.
>>
>> If the folder isn't owned by appropriate user, it moves to those steps:
>> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
>> itself as last step
>> 2. Fix /var/guix
>> 3. Fix /etc/guix
>> 4. Fix /var/log/guix
>>
>> So from those laid out steps it should be obvious that if guix-ownership
>> service somehow stops between steps 1 and 2, it will never recover
>> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
>> change owner as last.
>
> Well, the fundamental assumption is that =E2=80=98guix-ownership=E2=80=99=
 is not
> interrupted during its work; manual intervention is needed to repair
> things if it is interrupted.

I think it would at least be good if there was a script to do what
guix-ownership does, but force it without the /gnu/store ownership
check, to make it easier for users to recover. Maybe even an optional argum=
ent to
guix-ownership, where you could `sudo herd start guix-ownership 1` and
that would force the chown'ing?

>
> I don=E2=80=99t see any way around that but perhaps we should warn about =
it more
> clearly?

That would definitely be great, I think you can easily oversee that the
service has started. Now I am not sure if one-shot services are started
after change when you reconfigure, if they are, I think it's going to be
a common issue - people reconfigure & reboot! Meaning they will usually
stop the service, or am I mistaken here?

>
>> On the other hand it feels much of a coincidence users would be
>> consistently hitting reboots between those steps. So maybe I am
>> overlooking another thing. I checked the file-system-fold, it goes to
>> /gnu/store as last, so that would mean putting step 1 after 4 should fix
>> that. Still, maybe only /gnu/store itself should be skipped instead of m=
oving
>> the step, and done as last, step 5 to ensure it's fine even if
>> file-system-fold somehow changed the ordering? Not sure how exactly it
>> should behave in that regard.
>
> Doing /gnu/store last is a good idea because it reduces the window
> during which the inconsistent state could go undetected.

I think it completely removes it. Or why do you think not?
If it really doesn't I think it would be good if we came up with an
approach that would remove this window. The best way to achieve no
inconsistence-window would be to just check all of the permissions, but
that's probably an overkill.
For example creating a 'stamp'
somewhere that says it was done, at the end, and checking if that stamp
file matches what we expect.

>
> Feel free to propose a patch; otherwise I=E2=80=99ll give it a try, but n=
ot
> before next week.
>
> Thanks,
> Ludo=E2=80=99.

Thanks
Rutherther

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78355: guix-ownership inconsistent state
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 May 2025 08:34:02 +0000
Resent-Message-ID: <handler.78355.B78355.174729800021700 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78355
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Rutherther <rutherther@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org, Ben Sturmfels <ben@HIDDEN>
Received: via spool by 78355-submit <at> debbugs.gnu.org id=B78355.174729800021700
          (code B ref 78355); Thu, 15 May 2025 08:34:02 +0000
Received: (at 78355) by debbugs.gnu.org; 15 May 2025 08:33:20 +0000
Received: from localhost ([127.0.0.1]:50882 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uFU1o-0005du-1s
	for submit <at> debbugs.gnu.org; Thu, 15 May 2025 04:33:20 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:56652)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uFU1l-0005dU-5c
 for 78355 <at> debbugs.gnu.org; Thu, 15 May 2025 04:33:17 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uFU1e-00047I-Nm; Thu, 15 May 2025 04:33:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=edU64oEbDD8LrkXp/KSZ8xl64Nu6IOEr7xSF4+dhBFo=; b=af6NZsvdHU26bF0L8j1Q
 5x0kFMsEYo+n2Mhpyz9nprVPNByadtscNR+1sldB3r/EooGj6TAc7TDwdE8EM+ZVmXG0h4kNg+mqx
 /qSaqZ6p61fGIiCfgQDQNmBS7DPkNCtUM79LUpB8p+fh9sZBetjdr8uGKMe5ecNJNt9wiZmWDWK14
 dhepZZVo2tCB5nDgpUumozLJSTa8QeFl52frtFdtGu9kyaeDm7oqEoaZT7AysP6ghDiPINNnAGKQw
 HxAfni1Uh6gTyncIow1UmNzIqr4L3NP1F2oI2NZMWwdR711uZXBgN1msPMR69D1dB1hfXjASjhbpk
 az2HY58mQAZ3bg==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <87msbeuy07.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Thu, 15 May 2025 09:35:52 +0200")
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
 <87msbeuy07.fsf@HIDDEN>
User-Agent: mu4e 1.12.9; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Sextidi 26 =?UTF-8?Q?Flor=C3=A9al?= an 233 de la
 =?UTF-8?Q?R=C3=A9volution,?= jour du Fusain
Date: Thu, 15 May 2025 10:20:27 +0200
Message-ID: <87ecwqxp2s.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Hi,

Rutherther <rutherther@HIDDEN> writes:

> I think it would at least be good if there was a script to do what
> guix-ownership does, but force it without the /gnu/store ownership
> check, to make it easier for users to recover. Maybe even an optional arg=
ument to
> guix-ownership, where you could `sudo herd start guix-ownership 1` and
> that would force the chown'ing?

There=E2=80=99s +/- a script in the manual (info "(guix) Build Environment
Setup").

>>
>> I don=E2=80=99t see any way around that but perhaps we should warn about=
 it more
>> clearly?
>
> That would definitely be great, I think you can easily oversee that the
> service has started. Now I am not sure if one-shot services are started
> after change when you reconfigure, if they are, I think it's going to be
> a common issue - people reconfigure & reboot! Meaning they will usually
> stop the service, or am I mistaken here?

The one-shot service is restarted upon reconfigure, but one also has to
restart guix-daemon in this case.

>> Doing /gnu/store last is a good idea because it reduces the window
>> during which the inconsistent state could go undetected.
>
> I think it completely removes it. Or why do you think not?

Yes, you=E2=80=99re right, as long as /gnu/store itself is done last.

Ludo=E2=80=99.

Last modified: Thu, 15 May 2025 08:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.