GNU bug report logs - #76998
Guix Home leaves user shepherd on logout, starts new instance on login

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guix; Severity: important; Reported by: dannym@HIDDEN; merged with #67863, #74912; Done: Danny Milosavljevic <dannym@HIDDEN>; Maintainer for guix is bug-guix@HIDDEN.

Message received at 76998-done <at> debbugs.gnu.org:


Received: (at 76998-done) by debbugs.gnu.org; 18 May 2025 12:31:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 18 08:31:03 2025
Received: from localhost ([127.0.0.1]:56246 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uGdAV-00031c-3F
	for submit <at> debbugs.gnu.org; Sun, 18 May 2025 08:31:03 -0400
Received: from buffalo.ash.relay.mailchannels.net ([23.83.222.24]:51233)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <dannym@HIDDEN>)
 id 1uGdAQ-00030t-3e; Sun, 18 May 2025 08:30:59 -0400
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
Received: from relay.mailchannels.net (localhost [127.0.0.1])
 by relay.mailchannels.net (Postfix) with ESMTP id 346232C51FA;
 Sun, 18 May 2025 12:30:55 +0000 (UTC)
Received: from pdx1-sub0-mail-a211.dreamhost.com
 (trex-green-2.trex.outbound.svc.cluster.local [100.119.90.73])
 (Authenticated sender: dreamhost)
 by relay.mailchannels.net (Postfix) with ESMTPA id AAA522C5257;
 Sun, 18 May 2025 12:30:54 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1747571454; a=rsa-sha256;
 cv=none;
 b=imArXeROKjCyGVps0H8iAkoANz0QGLeaSoZ/S6S2LcbuL9Sy61O6Xw8o2m8Tvhd6THZW3l
 RfC6r8LQ6tHwxWLz+ih2GVkuzchAnxHsrxqDVjNMkL1SNgpRMUUbe8/NRPKcdg4W6WDwTY
 qntIN/AlVC7D57Lg5E7VmhTKt82jCQNzAsVRn6PB2MeR7xcCGFPeg8w/XN8Dsd4Vv+HOaE
 5Z+D1p12WKnuxZLyJgdIWokM9UEK1jC3xOYy47vmfgqGUTSRdShWSLzPrHRtadzuTvB/f9
 a/Qk6e8w79QXojYe2jsm91n+nSKfOs6I3wAx8plmp+d4Rgl3/sTK15YAn46+/w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=mailchannels.net; s=arc-2022; t=1747571454;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 dkim-signature; bh=lMUaJbrd91vDDt6ookEdYfqI3ddpLaGX55mkIqqtdTk=;
 b=AVGCrT5oBPh+mmJn7YZH0ua6hm+wz0hcY2HELnUycbkl0NNvpFFLT/hiRj9x/tXQ609JFS
 MlOyZ2cMsUxI+5kio7a70H3F7an7Lmy0PUaBPpLJYpXIe4FlCbHHLcvyasfG9WtIhSPDqR
 jfqsHkyBpJaXAkqIjmVP1dGv5StXvbaFbTaLIUtyiHEeCQCJ5Aqkk84TL2RJ8SlXf2PTza
 ai4/Z3+pIefgfDdGJbUk8f9A+uh7giAK0NZHrL0QJgc5ho6gN3ApMfq3093XqzuecktmEJ
 PXIdWOXG3KY/iHyC6OOoKG32Jrktx9tmQFqvyqDGsPEyeXPcholz+Jk2ZY9CHQ==
ARC-Authentication-Results: i=1; rspamd-766f9cfddb-ccm5x;
 auth=pass smtp.auth=dreamhost smtp.mailfrom=dannym@HIDDEN
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
X-MC-Relay: Neutral
X-MC-Copy: stored-urls
X-MailChannels-SenderId: dreamhost|x-authsender|dannym@HIDDEN
X-MailChannels-Auth-Id: dreamhost
X-Continue-Keen: 2bbd3f3209b40dda_1747571454960_4012650870
X-MC-Loop-Signature: 1747571454960:1570676293
X-MC-Ingress-Time: 1747571454960
Received: from pdx1-sub0-mail-a211.dreamhost.com (pop.dreamhost.com
 [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)
 by 100.119.90.73 (trex/7.0.3); Sun, 18 May 2025 12:30:54 +0000
Received: from nova (84-115-226-251.cable.dynamic.surfer.at [84.115.226.251])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 (Authenticated sender: dannym@HIDDEN)
 by pdx1-sub0-mail-a211.dreamhost.com (Postfix) with ESMTPSA id 4b0gCJ5gP8zLb; 
 Sun, 18 May 2025 05:30:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=friendly-machines.com; s=dreamhost; t=1747571454;
 bh=5S33FiyZ/SVSn2WJzLGLD7Ehkd67BOXqcqVLcbAdbUg=;
 h=From:To:Cc:Subject:Date:Content-Type;
 b=AZxHoJYDnenM+AeVc0Qg8dbql29vO4+zKeJaeeZp0AbRkfeBAuiG4Cb0FZXnTm1A/
 vcnKSX0rFMTORO2MlRvQU7s8lIriEXaZ0BSqEB4MKE+4/jy2z20U9sxNPA+s8vTh9z
 yCpWi0BEP92nHniyOywkA1Ri11XNa9b9ADF1YVZVfN6+3GtDmn/W3wsWk56L4HvInH
 3bBVquAscPfI1xy1oEY1hDhepDStio35OPyZKU7C8T5yfQFu4jfReDWgK0Mwp7mKza
 Ip8x0vT2+Ip5+armqQIyYNBvYpzhrYxTXf42KfbuwTzuPZpzNzlncUo5mMA6lRlPXC
 IGt4YnnvpgWOA==
From: Danny Milosavljevic <dannym@HIDDEN>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Subject: Re: bug#74912: bug#76998: Guix Home leaves user shepherd on logout,
 starts new instance on login
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 18 May 2025 14:30:49 +0200
Message-ID: <87bjrqt81y.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 3.6 (+++)
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:  Hi Ludo, That is not a fix. It's a workaround for now. It's
 good that the "is a shepherd already running" check is back in shepherd.
 It was in shepherd years ago, then got removed without explanation, then now
 it's back again (now in a very convoluted but [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [84.115.226.251 listed in zen.spamhaus.org]
 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.
 [23.83.222.24 listed in bl.score.senderscore.com]
 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.
 [23.83.222.24 listed in sa-trusted.bondedsender.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 RCVD_IN_MSPIKE_H5      RBL: Excellent reputation (+5)
 [23.83.222.24 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [23.83.222.24 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: 76998-done
Cc: 74912 <at> debbugs.gnu.org, 76998 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>,
 76998-done <at> debbugs.gnu.org, Jake <jforst.mailman@HIDDEN>,
 Daniel Littlewood <dan@HIDDEN>
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.6 (++)
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:  Hi Ludo, That is not a fix. It's a workaround for now. It's
    good that the "is a shepherd already running" check is back in shepherd.
   It was in shepherd years ago, then got removed without explanation, then now
    it's back again (now in a very convoluted but [...] 
 
 Content analysis details:   (2.6 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.
                             [23.83.222.24 listed in sa-accredit.habeas.com]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [84.115.226.251 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [23.83.222.24 listed in list.dnswl.org]
  0.0 RCVD_IN_MSPIKE_H5      RBL: Excellent reputation (+5)
                             [23.83.222.24 listed in wl.mailspike.net]
  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.
                             [23.83.222.24 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
  0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ludo,

That is not a fix.  It's a workaround for now.

It's good that the "is a shepherd already running" check is back in shepher=
d.  It was in shepherd years ago, then got removed without explanation, the=
n now it's back again (now in a very convoluted but safer way).  This shoul=
dn't have been removed in the first place.  It's EXTREMELY dangerous to hav=
e multiple parallel shepherds for the same user (automated backup service d=
estroying backups etc).  Please, let's not remove it ever again.

In any case, what shepherd 1.0.4 does is stop the bleeding, but not fix the=
 problem:
It prevents two (or 100) user shepherds for the same user from running in p=
arallel.
It does not stop shepherd when a user closed all their sessions.

Why close this bug report before elogind is patched and before ~/.bash_logo=
ut is generated in guix home?  That makes no sense.

Also, I don't understand why this is so broken for so long.  Isn't Guix use=
d in HPC?
Doesn't HPC need support for multiple sessions for the same user on day one?

My untested elogind patch that invokes shepherd root stop is attached.  Rea=
ding the elogind source code, especially what they patched out and what the=
y added themselves, makes me despair.  Why is it so terrible?  That all use=
d to be fine! :P

Even my patch is not great.  A service manager's job is to manage services.=
  PID 1 is the main service manager.  It should manage services.  One of th=
ose services should be the user's shepherd, which should be managed by PID =
1 shepherd and not weirdly attached to an already-running session (WTF!) of=
 the user by this:

~$ cat ~/.profile
HOME_ENVIRONMENT=3D$HOME/.guix-home
. $HOME_ENVIRONMENT/setup-environment
$HOME_ENVIRONMENT/on-first-login
unset HOME_ENVIRONMENT

In my opinion, no one but the service manager should manage services.  Does=
 ~/.profile look like a service manager?  No :P

I understand that we want to support this on non-guix-system stuff.  But th=
e default should be a systemd user service to run the user shepherd.  If th=
e user absolutely wants to do a workaround like ~/.profile above, fine, the=
y can.  But let's not do that by default.

The problems with my elogind patch are the following:
- What if "herd stop root -s ..." hangs?  Then elogind hangs forever?  No o=
ne can log in or out anymore?=C2=A0 That's not okay.  Therefore, I don't wa=
it.  Now user processes can have the floor upon they are walking removed on=
 user stop, while they still need it :P
- When can /run/user/1000 be deleted?  There's a weird GC mechanism in elog=
ind for that, and my patch says it can be deleted before waiting on the res=
ult of herd stop (see above why).  If I DID wait on the result of herd stop=
, I could wait indefinitely--which is not okay.  I think elogind uses signa=
lfd, so I can't waitpid in a random spot either, or wait until waitpid retu=
rned.  I think the user shepherd knows when to delete /run/user/1000--and n=
o one else.  But if user shepherd crashes, it won't delete /run/user/1000 a=
nd we want it to be able to start again even when /run/user/1000 is still t=
here.  Hence complicated shepherd fix in 1.0.4 is useful.
- There is tool_fork_pid and sleep_fork_pid in elogind which is not a queue=
.  And, again, that is trying to be a service manager.  What if those scrip=
ts hang?  What if they DON'T hang?  Similar questions as before.  Separate =
the concerns already :P

Personally, I'd also like something that, if all sessions of user x are clo=
sed, it kills all remaining processes of that effective user id.  elogind h=
as a setting KillUserProcesses that--despite the name--kills (WHICH!?) proc=
esses when a SESSION (of 42 sessions of that user :P) is closed.  Who wants=
 THAT?  And even if someone does: how would THAT be implemented?

elogind is like containers never happened.  It's so weird.

I think to fix this problem for good, first there needs to be a system diag=
ram created on how this is supposed to work.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=ELOGIND.patch
Content-Description: elogind patch for shepherd

License: elogind's license
Author: Danny Milosavljevic <dannym@HIDDEN>
Date: 2025-05-18

diff -ru orig/18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c 18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c
--- orig/18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c	2025-05-10 13:54:28.999814332 +0200
+++ 18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c	2025-05-10 15:48:33.872775240 +0200
@@ -2,6 +2,7 @@
 
 #include <errno.h>
 #include <unistd.h>
+#include <spawn.h>
 
 #include "alloc-util.h"
 //#include "bus-common-errors.h"
@@ -17,6 +18,7 @@
 #include "format-util.h"
 #include "fs-util.h"
 #include "hashmap.h"
+#include "string-util.h"
 // #include "label-util.h"
 #include "limits-util.h"
 #include "logind-dbus.h"
@@ -506,24 +508,45 @@
         return 0;
 }
 
-#if 0 /// elogind does not support user services and systemd units
 static void user_stop_service(User *u, bool force) {
-        _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL;
-        int r;
-
-        assert(u);
-        assert(u->service);
-
-        /* The reverse of user_start_service(). Note that we only stop user@HIDDEN here, and let StopWhenUnneeded=
-         * deal with the slice and the user-runtime-dir@.service instance. */
-
-        u->service_job = mfree(u->service_job);
-
-        r = manager_stop_unit(u->manager, u->service, force ? "replace" : "fail", &error, &u->service_job);
-        if (r < 0)
-                log_warning_errno(r, "Failed to stop user service '%s', ignoring: %s", u->service, bus_error_message(&error, r));
+	assert(u);
+	if (u->runtime_path != NULL) {
+		pid_t pid;
+		/* TODO: maybe just /run/booted-system/profile/bin/pkill -u u->user_record->uid ;
+		TODO: maybe just loginctl kill-user x; maybe that's us.
+		That eventually calls user_kill, which elogind patched to not kill the user
+		service or, really, do anything useful.
+		u->slice would be the unit name if it worked.
+		Note: u->user_record->kill_processes is for sessions, not users.
+		See also user_unit_active. */
+		const char *executable = "/run/booted-system/profile/bin/herd";
+		char* socket_path_arg = strjoina(u->runtime_path, "/shepherd/socket");
+		char *argv[] = {
+			(char *) executable,
+			"stop",
+			"root",
+			"-s",
+			socket_path_arg,
+			NULL,
+		};
+		int spawn_status = posix_spawn(&pid, executable, NULL, NULL, argv, environ);
+		if (spawn_status != 0) {
+			log_error_errno(spawn_status, "Failed to invoke %s: %m", executable);
+		} else {
+			if (u->manager != NULL) {
+				/* TODO: Do we overwrite someone here? */
+				u->manager->tool_fork_pid = pid;
+				/* elogind_sigchld_handler unsets it.  Not sure how we'd notice.
+				Note: elogind patched out the service_job handling which means
+				that user_may_gc will return true as soon as u->stopping == true
+				instead of checking whether the user service is still running. */
+			} else {
+				/* ??? */
+			}
+		}
+	}
+	user_add_to_gc_queue(u);
 }
-#endif // 0
 
 int user_stop(User *u, bool force) {
         int r = 0;
@@ -552,11 +575,7 @@
                         r = k;
         }
 
-#if 0 /// elogind does not support service or slice jobs...
         user_stop_service(u, force);
-#else // 0
-        user_add_to_gc_queue(u);
-#endif // 0
 
         u->stopping = true;
 

--=-=-=--




Notification sent to Jake <jforst.mailman@HIDDEN>:
bug acknowledged by developer. Full text available.
Reply sent to Danny Milosavljevic <dannym@HIDDEN>:
You have taken responsibility. Full text available.

Message received at 76998-done <at> debbugs.gnu.org:


Received: (at 76998-done) by debbugs.gnu.org; 18 May 2025 12:31:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 18 08:31:03 2025
Received: from localhost ([127.0.0.1]:56246 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uGdAV-00031c-3F
	for submit <at> debbugs.gnu.org; Sun, 18 May 2025 08:31:03 -0400
Received: from buffalo.ash.relay.mailchannels.net ([23.83.222.24]:51233)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <dannym@HIDDEN>)
 id 1uGdAQ-00030t-3e; Sun, 18 May 2025 08:30:59 -0400
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
Received: from relay.mailchannels.net (localhost [127.0.0.1])
 by relay.mailchannels.net (Postfix) with ESMTP id 346232C51FA;
 Sun, 18 May 2025 12:30:55 +0000 (UTC)
Received: from pdx1-sub0-mail-a211.dreamhost.com
 (trex-green-2.trex.outbound.svc.cluster.local [100.119.90.73])
 (Authenticated sender: dreamhost)
 by relay.mailchannels.net (Postfix) with ESMTPA id AAA522C5257;
 Sun, 18 May 2025 12:30:54 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1747571454; a=rsa-sha256;
 cv=none;
 b=imArXeROKjCyGVps0H8iAkoANz0QGLeaSoZ/S6S2LcbuL9Sy61O6Xw8o2m8Tvhd6THZW3l
 RfC6r8LQ6tHwxWLz+ih2GVkuzchAnxHsrxqDVjNMkL1SNgpRMUUbe8/NRPKcdg4W6WDwTY
 qntIN/AlVC7D57Lg5E7VmhTKt82jCQNzAsVRn6PB2MeR7xcCGFPeg8w/XN8Dsd4Vv+HOaE
 5Z+D1p12WKnuxZLyJgdIWokM9UEK1jC3xOYy47vmfgqGUTSRdShWSLzPrHRtadzuTvB/f9
 a/Qk6e8w79QXojYe2jsm91n+nSKfOs6I3wAx8plmp+d4Rgl3/sTK15YAn46+/w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=mailchannels.net; s=arc-2022; t=1747571454;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 dkim-signature; bh=lMUaJbrd91vDDt6ookEdYfqI3ddpLaGX55mkIqqtdTk=;
 b=AVGCrT5oBPh+mmJn7YZH0ua6hm+wz0hcY2HELnUycbkl0NNvpFFLT/hiRj9x/tXQ609JFS
 MlOyZ2cMsUxI+5kio7a70H3F7an7Lmy0PUaBPpLJYpXIe4FlCbHHLcvyasfG9WtIhSPDqR
 jfqsHkyBpJaXAkqIjmVP1dGv5StXvbaFbTaLIUtyiHEeCQCJ5Aqkk84TL2RJ8SlXf2PTza
 ai4/Z3+pIefgfDdGJbUk8f9A+uh7giAK0NZHrL0QJgc5ho6gN3ApMfq3093XqzuecktmEJ
 PXIdWOXG3KY/iHyC6OOoKG32Jrktx9tmQFqvyqDGsPEyeXPcholz+Jk2ZY9CHQ==
ARC-Authentication-Results: i=1; rspamd-766f9cfddb-ccm5x;
 auth=pass smtp.auth=dreamhost smtp.mailfrom=dannym@HIDDEN
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
X-MC-Relay: Neutral
X-MC-Copy: stored-urls
X-MailChannels-SenderId: dreamhost|x-authsender|dannym@HIDDEN
X-MailChannels-Auth-Id: dreamhost
X-Continue-Keen: 2bbd3f3209b40dda_1747571454960_4012650870
X-MC-Loop-Signature: 1747571454960:1570676293
X-MC-Ingress-Time: 1747571454960
Received: from pdx1-sub0-mail-a211.dreamhost.com (pop.dreamhost.com
 [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)
 by 100.119.90.73 (trex/7.0.3); Sun, 18 May 2025 12:30:54 +0000
Received: from nova (84-115-226-251.cable.dynamic.surfer.at [84.115.226.251])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 (Authenticated sender: dannym@HIDDEN)
 by pdx1-sub0-mail-a211.dreamhost.com (Postfix) with ESMTPSA id 4b0gCJ5gP8zLb; 
 Sun, 18 May 2025 05:30:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=friendly-machines.com; s=dreamhost; t=1747571454;
 bh=5S33FiyZ/SVSn2WJzLGLD7Ehkd67BOXqcqVLcbAdbUg=;
 h=From:To:Cc:Subject:Date:Content-Type;
 b=AZxHoJYDnenM+AeVc0Qg8dbql29vO4+zKeJaeeZp0AbRkfeBAuiG4Cb0FZXnTm1A/
 vcnKSX0rFMTORO2MlRvQU7s8lIriEXaZ0BSqEB4MKE+4/jy2z20U9sxNPA+s8vTh9z
 yCpWi0BEP92nHniyOywkA1Ri11XNa9b9ADF1YVZVfN6+3GtDmn/W3wsWk56L4HvInH
 3bBVquAscPfI1xy1oEY1hDhepDStio35OPyZKU7C8T5yfQFu4jfReDWgK0Mwp7mKza
 Ip8x0vT2+Ip5+armqQIyYNBvYpzhrYxTXf42KfbuwTzuPZpzNzlncUo5mMA6lRlPXC
 IGt4YnnvpgWOA==
From: Danny Milosavljevic <dannym@HIDDEN>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Subject: Re: bug#74912: bug#76998: Guix Home leaves user shepherd on logout,
 starts new instance on login
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 18 May 2025 14:30:49 +0200
Message-ID: <87bjrqt81y.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 3.6 (+++)
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:  Hi Ludo, That is not a fix. It's a workaround for now. It's
 good that the "is a shepherd already running" check is back in shepherd.
 It was in shepherd years ago, then got removed without explanation, then now
 it's back again (now in a very convoluted but [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [84.115.226.251 listed in zen.spamhaus.org]
 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.
 [23.83.222.24 listed in bl.score.senderscore.com]
 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.
 [23.83.222.24 listed in sa-trusted.bondedsender.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 RCVD_IN_MSPIKE_H5      RBL: Excellent reputation (+5)
 [23.83.222.24 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [23.83.222.24 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: 76998-done
Cc: 74912 <at> debbugs.gnu.org, 76998 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>,
 76998-done <at> debbugs.gnu.org, Jake <jforst.mailman@HIDDEN>,
 Daniel Littlewood <dan@HIDDEN>
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.6 (++)
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:  Hi Ludo, That is not a fix. It's a workaround for now. It's
    good that the "is a shepherd already running" check is back in shepherd.
   It was in shepherd years ago, then got removed without explanation, then now
    it's back again (now in a very convoluted but [...] 
 
 Content analysis details:   (2.6 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.
                             [23.83.222.24 listed in sa-accredit.habeas.com]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [84.115.226.251 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [23.83.222.24 listed in list.dnswl.org]
  0.0 RCVD_IN_MSPIKE_H5      RBL: Excellent reputation (+5)
                             [23.83.222.24 listed in wl.mailspike.net]
  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.
                             [23.83.222.24 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
  0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ludo,

That is not a fix.  It's a workaround for now.

It's good that the "is a shepherd already running" check is back in shepher=
d.  It was in shepherd years ago, then got removed without explanation, the=
n now it's back again (now in a very convoluted but safer way).  This shoul=
dn't have been removed in the first place.  It's EXTREMELY dangerous to hav=
e multiple parallel shepherds for the same user (automated backup service d=
estroying backups etc).  Please, let's not remove it ever again.

In any case, what shepherd 1.0.4 does is stop the bleeding, but not fix the=
 problem:
It prevents two (or 100) user shepherds for the same user from running in p=
arallel.
It does not stop shepherd when a user closed all their sessions.

Why close this bug report before elogind is patched and before ~/.bash_logo=
ut is generated in guix home?  That makes no sense.

Also, I don't understand why this is so broken for so long.  Isn't Guix use=
d in HPC?
Doesn't HPC need support for multiple sessions for the same user on day one?

My untested elogind patch that invokes shepherd root stop is attached.  Rea=
ding the elogind source code, especially what they patched out and what the=
y added themselves, makes me despair.  Why is it so terrible?  That all use=
d to be fine! :P

Even my patch is not great.  A service manager's job is to manage services.=
  PID 1 is the main service manager.  It should manage services.  One of th=
ose services should be the user's shepherd, which should be managed by PID =
1 shepherd and not weirdly attached to an already-running session (WTF!) of=
 the user by this:

~$ cat ~/.profile
HOME_ENVIRONMENT=3D$HOME/.guix-home
. $HOME_ENVIRONMENT/setup-environment
$HOME_ENVIRONMENT/on-first-login
unset HOME_ENVIRONMENT

In my opinion, no one but the service manager should manage services.  Does=
 ~/.profile look like a service manager?  No :P

I understand that we want to support this on non-guix-system stuff.  But th=
e default should be a systemd user service to run the user shepherd.  If th=
e user absolutely wants to do a workaround like ~/.profile above, fine, the=
y can.  But let's not do that by default.

The problems with my elogind patch are the following:
- What if "herd stop root -s ..." hangs?  Then elogind hangs forever?  No o=
ne can log in or out anymore?=C2=A0 That's not okay.  Therefore, I don't wa=
it.  Now user processes can have the floor upon they are walking removed on=
 user stop, while they still need it :P
- When can /run/user/1000 be deleted?  There's a weird GC mechanism in elog=
ind for that, and my patch says it can be deleted before waiting on the res=
ult of herd stop (see above why).  If I DID wait on the result of herd stop=
, I could wait indefinitely--which is not okay.  I think elogind uses signa=
lfd, so I can't waitpid in a random spot either, or wait until waitpid retu=
rned.  I think the user shepherd knows when to delete /run/user/1000--and n=
o one else.  But if user shepherd crashes, it won't delete /run/user/1000 a=
nd we want it to be able to start again even when /run/user/1000 is still t=
here.  Hence complicated shepherd fix in 1.0.4 is useful.
- There is tool_fork_pid and sleep_fork_pid in elogind which is not a queue=
.  And, again, that is trying to be a service manager.  What if those scrip=
ts hang?  What if they DON'T hang?  Similar questions as before.  Separate =
the concerns already :P

Personally, I'd also like something that, if all sessions of user x are clo=
sed, it kills all remaining processes of that effective user id.  elogind h=
as a setting KillUserProcesses that--despite the name--kills (WHICH!?) proc=
esses when a SESSION (of 42 sessions of that user :P) is closed.  Who wants=
 THAT?  And even if someone does: how would THAT be implemented?

elogind is like containers never happened.  It's so weird.

I think to fix this problem for good, first there needs to be a system diag=
ram created on how this is supposed to work.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=ELOGIND.patch
Content-Description: elogind patch for shepherd

License: elogind's license
Author: Danny Milosavljevic <dannym@HIDDEN>
Date: 2025-05-18

diff -ru orig/18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c 18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c
--- orig/18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c	2025-05-10 13:54:28.999814332 +0200
+++ 18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c	2025-05-10 15:48:33.872775240 +0200
@@ -2,6 +2,7 @@
 
 #include <errno.h>
 #include <unistd.h>
+#include <spawn.h>
 
 #include "alloc-util.h"
 //#include "bus-common-errors.h"
@@ -17,6 +18,7 @@
 #include "format-util.h"
 #include "fs-util.h"
 #include "hashmap.h"
+#include "string-util.h"
 // #include "label-util.h"
 #include "limits-util.h"
 #include "logind-dbus.h"
@@ -506,24 +508,45 @@
         return 0;
 }
 
-#if 0 /// elogind does not support user services and systemd units
 static void user_stop_service(User *u, bool force) {
-        _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL;
-        int r;
-
-        assert(u);
-        assert(u->service);
-
-        /* The reverse of user_start_service(). Note that we only stop user@HIDDEN here, and let StopWhenUnneeded=
-         * deal with the slice and the user-runtime-dir@.service instance. */
-
-        u->service_job = mfree(u->service_job);
-
-        r = manager_stop_unit(u->manager, u->service, force ? "replace" : "fail", &error, &u->service_job);
-        if (r < 0)
-                log_warning_errno(r, "Failed to stop user service '%s', ignoring: %s", u->service, bus_error_message(&error, r));
+	assert(u);
+	if (u->runtime_path != NULL) {
+		pid_t pid;
+		/* TODO: maybe just /run/booted-system/profile/bin/pkill -u u->user_record->uid ;
+		TODO: maybe just loginctl kill-user x; maybe that's us.
+		That eventually calls user_kill, which elogind patched to not kill the user
+		service or, really, do anything useful.
+		u->slice would be the unit name if it worked.
+		Note: u->user_record->kill_processes is for sessions, not users.
+		See also user_unit_active. */
+		const char *executable = "/run/booted-system/profile/bin/herd";
+		char* socket_path_arg = strjoina(u->runtime_path, "/shepherd/socket");
+		char *argv[] = {
+			(char *) executable,
+			"stop",
+			"root",
+			"-s",
+			socket_path_arg,
+			NULL,
+		};
+		int spawn_status = posix_spawn(&pid, executable, NULL, NULL, argv, environ);
+		if (spawn_status != 0) {
+			log_error_errno(spawn_status, "Failed to invoke %s: %m", executable);
+		} else {
+			if (u->manager != NULL) {
+				/* TODO: Do we overwrite someone here? */
+				u->manager->tool_fork_pid = pid;
+				/* elogind_sigchld_handler unsets it.  Not sure how we'd notice.
+				Note: elogind patched out the service_job handling which means
+				that user_may_gc will return true as soon as u->stopping == true
+				instead of checking whether the user service is still running. */
+			} else {
+				/* ??? */
+			}
+		}
+	}
+	user_add_to_gc_queue(u);
 }
-#endif // 0
 
 int user_stop(User *u, bool force) {
         int r = 0;
@@ -552,11 +575,7 @@
                         r = k;
         }
 
-#if 0 /// elogind does not support service or slice jobs...
         user_stop_service(u, force);
-#else // 0
-        user_add_to_gc_queue(u);
-#endif // 0
 
         u->stopping = true;
 

--=-=-=--




Notification sent to xeji@HIDDEN:
bug acknowledged by developer. Full text available.
Reply sent to Danny Milosavljevic <dannym@HIDDEN>:
You have taken responsibility. Full text available.

Message received at 76998-done <at> debbugs.gnu.org:


Received: (at 76998-done) by debbugs.gnu.org; 18 May 2025 12:31:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 18 08:31:03 2025
Received: from localhost ([127.0.0.1]:56246 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uGdAV-00031c-3F
	for submit <at> debbugs.gnu.org; Sun, 18 May 2025 08:31:03 -0400
Received: from buffalo.ash.relay.mailchannels.net ([23.83.222.24]:51233)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <dannym@HIDDEN>)
 id 1uGdAQ-00030t-3e; Sun, 18 May 2025 08:30:59 -0400
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
Received: from relay.mailchannels.net (localhost [127.0.0.1])
 by relay.mailchannels.net (Postfix) with ESMTP id 346232C51FA;
 Sun, 18 May 2025 12:30:55 +0000 (UTC)
Received: from pdx1-sub0-mail-a211.dreamhost.com
 (trex-green-2.trex.outbound.svc.cluster.local [100.119.90.73])
 (Authenticated sender: dreamhost)
 by relay.mailchannels.net (Postfix) with ESMTPA id AAA522C5257;
 Sun, 18 May 2025 12:30:54 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1747571454; a=rsa-sha256;
 cv=none;
 b=imArXeROKjCyGVps0H8iAkoANz0QGLeaSoZ/S6S2LcbuL9Sy61O6Xw8o2m8Tvhd6THZW3l
 RfC6r8LQ6tHwxWLz+ih2GVkuzchAnxHsrxqDVjNMkL1SNgpRMUUbe8/NRPKcdg4W6WDwTY
 qntIN/AlVC7D57Lg5E7VmhTKt82jCQNzAsVRn6PB2MeR7xcCGFPeg8w/XN8Dsd4Vv+HOaE
 5Z+D1p12WKnuxZLyJgdIWokM9UEK1jC3xOYy47vmfgqGUTSRdShWSLzPrHRtadzuTvB/f9
 a/Qk6e8w79QXojYe2jsm91n+nSKfOs6I3wAx8plmp+d4Rgl3/sTK15YAn46+/w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=mailchannels.net; s=arc-2022; t=1747571454;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 dkim-signature; bh=lMUaJbrd91vDDt6ookEdYfqI3ddpLaGX55mkIqqtdTk=;
 b=AVGCrT5oBPh+mmJn7YZH0ua6hm+wz0hcY2HELnUycbkl0NNvpFFLT/hiRj9x/tXQ609JFS
 MlOyZ2cMsUxI+5kio7a70H3F7an7Lmy0PUaBPpLJYpXIe4FlCbHHLcvyasfG9WtIhSPDqR
 jfqsHkyBpJaXAkqIjmVP1dGv5StXvbaFbTaLIUtyiHEeCQCJ5Aqkk84TL2RJ8SlXf2PTza
 ai4/Z3+pIefgfDdGJbUk8f9A+uh7giAK0NZHrL0QJgc5ho6gN3ApMfq3093XqzuecktmEJ
 PXIdWOXG3KY/iHyC6OOoKG32Jrktx9tmQFqvyqDGsPEyeXPcholz+Jk2ZY9CHQ==
ARC-Authentication-Results: i=1; rspamd-766f9cfddb-ccm5x;
 auth=pass smtp.auth=dreamhost smtp.mailfrom=dannym@HIDDEN
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
X-MC-Relay: Neutral
X-MC-Copy: stored-urls
X-MailChannels-SenderId: dreamhost|x-authsender|dannym@HIDDEN
X-MailChannels-Auth-Id: dreamhost
X-Continue-Keen: 2bbd3f3209b40dda_1747571454960_4012650870
X-MC-Loop-Signature: 1747571454960:1570676293
X-MC-Ingress-Time: 1747571454960
Received: from pdx1-sub0-mail-a211.dreamhost.com (pop.dreamhost.com
 [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)
 by 100.119.90.73 (trex/7.0.3); Sun, 18 May 2025 12:30:54 +0000
Received: from nova (84-115-226-251.cable.dynamic.surfer.at [84.115.226.251])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 (Authenticated sender: dannym@HIDDEN)
 by pdx1-sub0-mail-a211.dreamhost.com (Postfix) with ESMTPSA id 4b0gCJ5gP8zLb; 
 Sun, 18 May 2025 05:30:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=friendly-machines.com; s=dreamhost; t=1747571454;
 bh=5S33FiyZ/SVSn2WJzLGLD7Ehkd67BOXqcqVLcbAdbUg=;
 h=From:To:Cc:Subject:Date:Content-Type;
 b=AZxHoJYDnenM+AeVc0Qg8dbql29vO4+zKeJaeeZp0AbRkfeBAuiG4Cb0FZXnTm1A/
 vcnKSX0rFMTORO2MlRvQU7s8lIriEXaZ0BSqEB4MKE+4/jy2z20U9sxNPA+s8vTh9z
 yCpWi0BEP92nHniyOywkA1Ri11XNa9b9ADF1YVZVfN6+3GtDmn/W3wsWk56L4HvInH
 3bBVquAscPfI1xy1oEY1hDhepDStio35OPyZKU7C8T5yfQFu4jfReDWgK0Mwp7mKza
 Ip8x0vT2+Ip5+armqQIyYNBvYpzhrYxTXf42KfbuwTzuPZpzNzlncUo5mMA6lRlPXC
 IGt4YnnvpgWOA==
From: Danny Milosavljevic <dannym@HIDDEN>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Subject: Re: bug#74912: bug#76998: Guix Home leaves user shepherd on logout,
 starts new instance on login
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 18 May 2025 14:30:49 +0200
Message-ID: <87bjrqt81y.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 3.6 (+++)
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:  Hi Ludo, That is not a fix. It's a workaround for now. It's
 good that the "is a shepherd already running" check is back in shepherd.
 It was in shepherd years ago, then got removed without explanation, then now
 it's back again (now in a very convoluted but [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [84.115.226.251 listed in zen.spamhaus.org]
 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.
 [23.83.222.24 listed in bl.score.senderscore.com]
 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.
 [23.83.222.24 listed in sa-trusted.bondedsender.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 RCVD_IN_MSPIKE_H5      RBL: Excellent reputation (+5)
 [23.83.222.24 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [23.83.222.24 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: 76998-done
Cc: 74912 <at> debbugs.gnu.org, 76998 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>,
 76998-done <at> debbugs.gnu.org, Jake <jforst.mailman@HIDDEN>,
 Daniel Littlewood <dan@HIDDEN>
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.6 (++)
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:  Hi Ludo, That is not a fix. It's a workaround for now. It's
    good that the "is a shepherd already running" check is back in shepherd.
   It was in shepherd years ago, then got removed without explanation, then now
    it's back again (now in a very convoluted but [...] 
 
 Content analysis details:   (2.6 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.
                             [23.83.222.24 listed in sa-accredit.habeas.com]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [84.115.226.251 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [23.83.222.24 listed in list.dnswl.org]
  0.0 RCVD_IN_MSPIKE_H5      RBL: Excellent reputation (+5)
                             [23.83.222.24 listed in wl.mailspike.net]
  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.
                             [23.83.222.24 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
  0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ludo,

That is not a fix.  It's a workaround for now.

It's good that the "is a shepherd already running" check is back in shepher=
d.  It was in shepherd years ago, then got removed without explanation, the=
n now it's back again (now in a very convoluted but safer way).  This shoul=
dn't have been removed in the first place.  It's EXTREMELY dangerous to hav=
e multiple parallel shepherds for the same user (automated backup service d=
estroying backups etc).  Please, let's not remove it ever again.

In any case, what shepherd 1.0.4 does is stop the bleeding, but not fix the=
 problem:
It prevents two (or 100) user shepherds for the same user from running in p=
arallel.
It does not stop shepherd when a user closed all their sessions.

Why close this bug report before elogind is patched and before ~/.bash_logo=
ut is generated in guix home?  That makes no sense.

Also, I don't understand why this is so broken for so long.  Isn't Guix use=
d in HPC?
Doesn't HPC need support for multiple sessions for the same user on day one?

My untested elogind patch that invokes shepherd root stop is attached.  Rea=
ding the elogind source code, especially what they patched out and what the=
y added themselves, makes me despair.  Why is it so terrible?  That all use=
d to be fine! :P

Even my patch is not great.  A service manager's job is to manage services.=
  PID 1 is the main service manager.  It should manage services.  One of th=
ose services should be the user's shepherd, which should be managed by PID =
1 shepherd and not weirdly attached to an already-running session (WTF!) of=
 the user by this:

~$ cat ~/.profile
HOME_ENVIRONMENT=3D$HOME/.guix-home
. $HOME_ENVIRONMENT/setup-environment
$HOME_ENVIRONMENT/on-first-login
unset HOME_ENVIRONMENT

In my opinion, no one but the service manager should manage services.  Does=
 ~/.profile look like a service manager?  No :P

I understand that we want to support this on non-guix-system stuff.  But th=
e default should be a systemd user service to run the user shepherd.  If th=
e user absolutely wants to do a workaround like ~/.profile above, fine, the=
y can.  But let's not do that by default.

The problems with my elogind patch are the following:
- What if "herd stop root -s ..." hangs?  Then elogind hangs forever?  No o=
ne can log in or out anymore?=C2=A0 That's not okay.  Therefore, I don't wa=
it.  Now user processes can have the floor upon they are walking removed on=
 user stop, while they still need it :P
- When can /run/user/1000 be deleted?  There's a weird GC mechanism in elog=
ind for that, and my patch says it can be deleted before waiting on the res=
ult of herd stop (see above why).  If I DID wait on the result of herd stop=
, I could wait indefinitely--which is not okay.  I think elogind uses signa=
lfd, so I can't waitpid in a random spot either, or wait until waitpid retu=
rned.  I think the user shepherd knows when to delete /run/user/1000--and n=
o one else.  But if user shepherd crashes, it won't delete /run/user/1000 a=
nd we want it to be able to start again even when /run/user/1000 is still t=
here.  Hence complicated shepherd fix in 1.0.4 is useful.
- There is tool_fork_pid and sleep_fork_pid in elogind which is not a queue=
.  And, again, that is trying to be a service manager.  What if those scrip=
ts hang?  What if they DON'T hang?  Similar questions as before.  Separate =
the concerns already :P

Personally, I'd also like something that, if all sessions of user x are clo=
sed, it kills all remaining processes of that effective user id.  elogind h=
as a setting KillUserProcesses that--despite the name--kills (WHICH!?) proc=
esses when a SESSION (of 42 sessions of that user :P) is closed.  Who wants=
 THAT?  And even if someone does: how would THAT be implemented?

elogind is like containers never happened.  It's so weird.

I think to fix this problem for good, first there needs to be a system diag=
ram created on how this is supposed to work.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=ELOGIND.patch
Content-Description: elogind patch for shepherd

License: elogind's license
Author: Danny Milosavljevic <dannym@HIDDEN>
Date: 2025-05-18

diff -ru orig/18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c 18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c
--- orig/18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c	2025-05-10 13:54:28.999814332 +0200
+++ 18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c	2025-05-10 15:48:33.872775240 +0200
@@ -2,6 +2,7 @@
 
 #include <errno.h>
 #include <unistd.h>
+#include <spawn.h>
 
 #include "alloc-util.h"
 //#include "bus-common-errors.h"
@@ -17,6 +18,7 @@
 #include "format-util.h"
 #include "fs-util.h"
 #include "hashmap.h"
+#include "string-util.h"
 // #include "label-util.h"
 #include "limits-util.h"
 #include "logind-dbus.h"
@@ -506,24 +508,45 @@
         return 0;
 }
 
-#if 0 /// elogind does not support user services and systemd units
 static void user_stop_service(User *u, bool force) {
-        _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL;
-        int r;
-
-        assert(u);
-        assert(u->service);
-
-        /* The reverse of user_start_service(). Note that we only stop user@HIDDEN here, and let StopWhenUnneeded=
-         * deal with the slice and the user-runtime-dir@.service instance. */
-
-        u->service_job = mfree(u->service_job);
-
-        r = manager_stop_unit(u->manager, u->service, force ? "replace" : "fail", &error, &u->service_job);
-        if (r < 0)
-                log_warning_errno(r, "Failed to stop user service '%s', ignoring: %s", u->service, bus_error_message(&error, r));
+	assert(u);
+	if (u->runtime_path != NULL) {
+		pid_t pid;
+		/* TODO: maybe just /run/booted-system/profile/bin/pkill -u u->user_record->uid ;
+		TODO: maybe just loginctl kill-user x; maybe that's us.
+		That eventually calls user_kill, which elogind patched to not kill the user
+		service or, really, do anything useful.
+		u->slice would be the unit name if it worked.
+		Note: u->user_record->kill_processes is for sessions, not users.
+		See also user_unit_active. */
+		const char *executable = "/run/booted-system/profile/bin/herd";
+		char* socket_path_arg = strjoina(u->runtime_path, "/shepherd/socket");
+		char *argv[] = {
+			(char *) executable,
+			"stop",
+			"root",
+			"-s",
+			socket_path_arg,
+			NULL,
+		};
+		int spawn_status = posix_spawn(&pid, executable, NULL, NULL, argv, environ);
+		if (spawn_status != 0) {
+			log_error_errno(spawn_status, "Failed to invoke %s: %m", executable);
+		} else {
+			if (u->manager != NULL) {
+				/* TODO: Do we overwrite someone here? */
+				u->manager->tool_fork_pid = pid;
+				/* elogind_sigchld_handler unsets it.  Not sure how we'd notice.
+				Note: elogind patched out the service_job handling which means
+				that user_may_gc will return true as soon as u->stopping == true
+				instead of checking whether the user service is still running. */
+			} else {
+				/* ??? */
+			}
+		}
+	}
+	user_add_to_gc_queue(u);
 }
-#endif // 0
 
 int user_stop(User *u, bool force) {
         int r = 0;
@@ -552,11 +575,7 @@
                         r = k;
         }
 
-#if 0 /// elogind does not support service or slice jobs...
         user_stop_service(u, force);
-#else // 0
-        user_add_to_gc_queue(u);
-#endif // 0
 
         u->stopping = true;
 

--=-=-=--




Notification sent to dannym@HIDDEN:
bug acknowledged by developer. Full text available.
Reply sent to Danny Milosavljevic <dannym@HIDDEN>:
You have taken responsibility. Full text available.

Message received at 76998 <at> debbugs.gnu.org:


Received: (at 76998) by debbugs.gnu.org; 18 May 2025 12:31:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 18 08:31:09 2025
Received: from localhost ([127.0.0.1]:56248 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uGdAb-00031v-2d
	for submit <at> debbugs.gnu.org; Sun, 18 May 2025 08:31:09 -0400
Received: from buffalo.ash.relay.mailchannels.net ([23.83.222.24]:51233)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <dannym@HIDDEN>)
 id 1uGdAQ-00030t-3e; Sun, 18 May 2025 08:30:59 -0400
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
Received: from relay.mailchannels.net (localhost [127.0.0.1])
 by relay.mailchannels.net (Postfix) with ESMTP id 346232C51FA;
 Sun, 18 May 2025 12:30:55 +0000 (UTC)
Received: from pdx1-sub0-mail-a211.dreamhost.com
 (trex-green-2.trex.outbound.svc.cluster.local [100.119.90.73])
 (Authenticated sender: dreamhost)
 by relay.mailchannels.net (Postfix) with ESMTPA id AAA522C5257;
 Sun, 18 May 2025 12:30:54 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1747571454; a=rsa-sha256;
 cv=none;
 b=imArXeROKjCyGVps0H8iAkoANz0QGLeaSoZ/S6S2LcbuL9Sy61O6Xw8o2m8Tvhd6THZW3l
 RfC6r8LQ6tHwxWLz+ih2GVkuzchAnxHsrxqDVjNMkL1SNgpRMUUbe8/NRPKcdg4W6WDwTY
 qntIN/AlVC7D57Lg5E7VmhTKt82jCQNzAsVRn6PB2MeR7xcCGFPeg8w/XN8Dsd4Vv+HOaE
 5Z+D1p12WKnuxZLyJgdIWokM9UEK1jC3xOYy47vmfgqGUTSRdShWSLzPrHRtadzuTvB/f9
 a/Qk6e8w79QXojYe2jsm91n+nSKfOs6I3wAx8plmp+d4Rgl3/sTK15YAn46+/w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=mailchannels.net; s=arc-2022; t=1747571454;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 dkim-signature; bh=lMUaJbrd91vDDt6ookEdYfqI3ddpLaGX55mkIqqtdTk=;
 b=AVGCrT5oBPh+mmJn7YZH0ua6hm+wz0hcY2HELnUycbkl0NNvpFFLT/hiRj9x/tXQ609JFS
 MlOyZ2cMsUxI+5kio7a70H3F7an7Lmy0PUaBPpLJYpXIe4FlCbHHLcvyasfG9WtIhSPDqR
 jfqsHkyBpJaXAkqIjmVP1dGv5StXvbaFbTaLIUtyiHEeCQCJ5Aqkk84TL2RJ8SlXf2PTza
 ai4/Z3+pIefgfDdGJbUk8f9A+uh7giAK0NZHrL0QJgc5ho6gN3ApMfq3093XqzuecktmEJ
 PXIdWOXG3KY/iHyC6OOoKG32Jrktx9tmQFqvyqDGsPEyeXPcholz+Jk2ZY9CHQ==
ARC-Authentication-Results: i=1; rspamd-766f9cfddb-ccm5x;
 auth=pass smtp.auth=dreamhost smtp.mailfrom=dannym@HIDDEN
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
X-MC-Relay: Neutral
X-MC-Copy: stored-urls
X-MailChannels-SenderId: dreamhost|x-authsender|dannym@HIDDEN
X-MailChannels-Auth-Id: dreamhost
X-Continue-Keen: 2bbd3f3209b40dda_1747571454960_4012650870
X-MC-Loop-Signature: 1747571454960:1570676293
X-MC-Ingress-Time: 1747571454960
Received: from pdx1-sub0-mail-a211.dreamhost.com (pop.dreamhost.com
 [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)
 by 100.119.90.73 (trex/7.0.3); Sun, 18 May 2025 12:30:54 +0000
Received: from nova (84-115-226-251.cable.dynamic.surfer.at [84.115.226.251])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 (Authenticated sender: dannym@HIDDEN)
 by pdx1-sub0-mail-a211.dreamhost.com (Postfix) with ESMTPSA id 4b0gCJ5gP8zLb; 
 Sun, 18 May 2025 05:30:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=friendly-machines.com; s=dreamhost; t=1747571454;
 bh=5S33FiyZ/SVSn2WJzLGLD7Ehkd67BOXqcqVLcbAdbUg=;
 h=From:To:Cc:Subject:Date:Content-Type;
 b=AZxHoJYDnenM+AeVc0Qg8dbql29vO4+zKeJaeeZp0AbRkfeBAuiG4Cb0FZXnTm1A/
 vcnKSX0rFMTORO2MlRvQU7s8lIriEXaZ0BSqEB4MKE+4/jy2z20U9sxNPA+s8vTh9z
 yCpWi0BEP92nHniyOywkA1Ri11XNa9b9ADF1YVZVfN6+3GtDmn/W3wsWk56L4HvInH
 3bBVquAscPfI1xy1oEY1hDhepDStio35OPyZKU7C8T5yfQFu4jfReDWgK0Mwp7mKza
 Ip8x0vT2+Ip5+armqQIyYNBvYpzhrYxTXf42KfbuwTzuPZpzNzlncUo5mMA6lRlPXC
 IGt4YnnvpgWOA==
From: Danny Milosavljevic <dannym@HIDDEN>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Subject: Re: bug#74912: bug#76998: Guix Home leaves user shepherd on logout,
 starts new instance on login
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 18 May 2025 14:30:49 +0200
Message-ID: <87bjrqt81y.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 3.6 (+++)
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:  Hi Ludo, That is not a fix. It's a workaround for now. It's
 good that the "is a shepherd already running" check is back in shepherd.
 It was in shepherd years ago, then got removed without explanation, then now
 it's back again (now in a very convoluted but [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [84.115.226.251 listed in zen.spamhaus.org]
 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.
 [23.83.222.24 listed in bl.score.senderscore.com]
 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.
 [23.83.222.24 listed in sa-trusted.bondedsender.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 RCVD_IN_MSPIKE_H5      RBL: Excellent reputation (+5)
 [23.83.222.24 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [23.83.222.24 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: 76998
Cc: 74912 <at> debbugs.gnu.org, 76998 <at> debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>,
 76998-done <at> debbugs.gnu.org, Jake <jforst.mailman@HIDDEN>,
 Daniel Littlewood <dan@HIDDEN>
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.6 (++)
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:  Hi Ludo, That is not a fix. It's a workaround for now. It's
    good that the "is a shepherd already running" check is back in shepherd.
   It was in shepherd years ago, then got removed without explanation, then now
    it's back again (now in a very convoluted but [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [84.115.226.251 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [23.83.222.24 listed in list.dnswl.org]
  0.0 RCVD_IN_MSPIKE_H5      RBL: Excellent reputation (+5)
                             [23.83.222.24 listed in wl.mailspike.net]
  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.
                             [23.83.222.24 listed in bl.score.senderscore.com]
  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.
                             [23.83.222.24 listed in sa-accredit.habeas.com]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ludo,

That is not a fix.  It's a workaround for now.

It's good that the "is a shepherd already running" check is back in shepher=
d.  It was in shepherd years ago, then got removed without explanation, the=
n now it's back again (now in a very convoluted but safer way).  This shoul=
dn't have been removed in the first place.  It's EXTREMELY dangerous to hav=
e multiple parallel shepherds for the same user (automated backup service d=
estroying backups etc).  Please, let's not remove it ever again.

In any case, what shepherd 1.0.4 does is stop the bleeding, but not fix the=
 problem:
It prevents two (or 100) user shepherds for the same user from running in p=
arallel.
It does not stop shepherd when a user closed all their sessions.

Why close this bug report before elogind is patched and before ~/.bash_logo=
ut is generated in guix home?  That makes no sense.

Also, I don't understand why this is so broken for so long.  Isn't Guix use=
d in HPC?
Doesn't HPC need support for multiple sessions for the same user on day one?

My untested elogind patch that invokes shepherd root stop is attached.  Rea=
ding the elogind source code, especially what they patched out and what the=
y added themselves, makes me despair.  Why is it so terrible?  That all use=
d to be fine! :P

Even my patch is not great.  A service manager's job is to manage services.=
  PID 1 is the main service manager.  It should manage services.  One of th=
ose services should be the user's shepherd, which should be managed by PID =
1 shepherd and not weirdly attached to an already-running session (WTF!) of=
 the user by this:

~$ cat ~/.profile
HOME_ENVIRONMENT=3D$HOME/.guix-home
. $HOME_ENVIRONMENT/setup-environment
$HOME_ENVIRONMENT/on-first-login
unset HOME_ENVIRONMENT

In my opinion, no one but the service manager should manage services.  Does=
 ~/.profile look like a service manager?  No :P

I understand that we want to support this on non-guix-system stuff.  But th=
e default should be a systemd user service to run the user shepherd.  If th=
e user absolutely wants to do a workaround like ~/.profile above, fine, the=
y can.  But let's not do that by default.

The problems with my elogind patch are the following:
- What if "herd stop root -s ..." hangs?  Then elogind hangs forever?  No o=
ne can log in or out anymore?=C2=A0 That's not okay.  Therefore, I don't wa=
it.  Now user processes can have the floor upon they are walking removed on=
 user stop, while they still need it :P
- When can /run/user/1000 be deleted?  There's a weird GC mechanism in elog=
ind for that, and my patch says it can be deleted before waiting on the res=
ult of herd stop (see above why).  If I DID wait on the result of herd stop=
, I could wait indefinitely--which is not okay.  I think elogind uses signa=
lfd, so I can't waitpid in a random spot either, or wait until waitpid retu=
rned.  I think the user shepherd knows when to delete /run/user/1000--and n=
o one else.  But if user shepherd crashes, it won't delete /run/user/1000 a=
nd we want it to be able to start again even when /run/user/1000 is still t=
here.  Hence complicated shepherd fix in 1.0.4 is useful.
- There is tool_fork_pid and sleep_fork_pid in elogind which is not a queue=
.  And, again, that is trying to be a service manager.  What if those scrip=
ts hang?  What if they DON'T hang?  Similar questions as before.  Separate =
the concerns already :P

Personally, I'd also like something that, if all sessions of user x are clo=
sed, it kills all remaining processes of that effective user id.  elogind h=
as a setting KillUserProcesses that--despite the name--kills (WHICH!?) proc=
esses when a SESSION (of 42 sessions of that user :P) is closed.  Who wants=
 THAT?  And even if someone does: how would THAT be implemented?

elogind is like containers never happened.  It's so weird.

I think to fix this problem for good, first there needs to be a system diag=
ram created on how this is supposed to work.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=ELOGIND.patch
Content-Description: elogind patch for shepherd

License: elogind's license
Author: Danny Milosavljevic <dannym@HIDDEN>
Date: 2025-05-18

diff -ru orig/18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c 18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c
--- orig/18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c	2025-05-10 13:54:28.999814332 +0200
+++ 18rk21n7l3yniy1rvlcdnwgnnvafivf0-elogind-255.17-checkout/src/login/logind-user.c	2025-05-10 15:48:33.872775240 +0200
@@ -2,6 +2,7 @@
 
 #include <errno.h>
 #include <unistd.h>
+#include <spawn.h>
 
 #include "alloc-util.h"
 //#include "bus-common-errors.h"
@@ -17,6 +18,7 @@
 #include "format-util.h"
 #include "fs-util.h"
 #include "hashmap.h"
+#include "string-util.h"
 // #include "label-util.h"
 #include "limits-util.h"
 #include "logind-dbus.h"
@@ -506,24 +508,45 @@
         return 0;
 }
 
-#if 0 /// elogind does not support user services and systemd units
 static void user_stop_service(User *u, bool force) {
-        _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL;
-        int r;
-
-        assert(u);
-        assert(u->service);
-
-        /* The reverse of user_start_service(). Note that we only stop user@HIDDEN here, and let StopWhenUnneeded=
-         * deal with the slice and the user-runtime-dir@.service instance. */
-
-        u->service_job = mfree(u->service_job);
-
-        r = manager_stop_unit(u->manager, u->service, force ? "replace" : "fail", &error, &u->service_job);
-        if (r < 0)
-                log_warning_errno(r, "Failed to stop user service '%s', ignoring: %s", u->service, bus_error_message(&error, r));
+	assert(u);
+	if (u->runtime_path != NULL) {
+		pid_t pid;
+		/* TODO: maybe just /run/booted-system/profile/bin/pkill -u u->user_record->uid ;
+		TODO: maybe just loginctl kill-user x; maybe that's us.
+		That eventually calls user_kill, which elogind patched to not kill the user
+		service or, really, do anything useful.
+		u->slice would be the unit name if it worked.
+		Note: u->user_record->kill_processes is for sessions, not users.
+		See also user_unit_active. */
+		const char *executable = "/run/booted-system/profile/bin/herd";
+		char* socket_path_arg = strjoina(u->runtime_path, "/shepherd/socket");
+		char *argv[] = {
+			(char *) executable,
+			"stop",
+			"root",
+			"-s",
+			socket_path_arg,
+			NULL,
+		};
+		int spawn_status = posix_spawn(&pid, executable, NULL, NULL, argv, environ);
+		if (spawn_status != 0) {
+			log_error_errno(spawn_status, "Failed to invoke %s: %m", executable);
+		} else {
+			if (u->manager != NULL) {
+				/* TODO: Do we overwrite someone here? */
+				u->manager->tool_fork_pid = pid;
+				/* elogind_sigchld_handler unsets it.  Not sure how we'd notice.
+				Note: elogind patched out the service_job handling which means
+				that user_may_gc will return true as soon as u->stopping == true
+				instead of checking whether the user service is still running. */
+			} else {
+				/* ??? */
+			}
+		}
+	}
+	user_add_to_gc_queue(u);
 }
-#endif // 0
 
 int user_stop(User *u, bool force) {
         int r = 0;
@@ -552,11 +575,7 @@
                         r = k;
         }
 
-#if 0 /// elogind does not support service or slice jobs...
         user_stop_service(u, force);
-#else // 0
-        user_add_to_gc_queue(u);
-#endif // 0
 
         u->stopping = true;
 

--=-=-=--




Information forwarded to bug-guix@HIDDEN:
bug#76998; Package guix. Full text available.
Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <help-debbugs@HIDDEN> to internal_control <at> debbugs.gnu.org. Full text available.

Message received at 76998-done <at> debbugs.gnu.org:


Received: (at 76998-done) by debbugs.gnu.org; 14 May 2025 17:04:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 13:04:08 2025
Received: from localhost ([127.0.0.1]:44765 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uFFWZ-0004oD-UN
	for submit <at> debbugs.gnu.org; Wed, 14 May 2025 13:04:08 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:37298)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>)
 id 1uFFWR-0004m8-U2; Wed, 14 May 2025 13:04:02 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 051E0E30;
 Wed, 14 May 2025 19:03:54 +0200 (CEST)
X-Virus-Scanned: Debian amavis at hera.aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavis, port 10024) with ESMTP
 id Ev7yrxHP5FOJ; Wed, 14 May 2025 19:03:53 +0200 (CEST)
Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 4472BD96;
 Wed, 14 May 2025 19:03:53 +0200 (CEST)
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Danny Milosavljevic <dannym@HIDDEN>
Subject: Re: bug#76998: Guix Home leaves user shepherd on logout, starts new
 instance on login
In-Reply-To: <874iyrkvx7.fsf@HIDDEN> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
 =?utf-8?Q?s?= message of "Mon, 14 Apr 2025 10:08:04 +0200")
References: <871pukdlyo.fsf@HIDDEN> <874iyrkvx7.fsf@HIDDEN>
Date: Wed, 14 May 2025 18:06:11 +0200
Message-ID: <87tt5nyy6k.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
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 76998-done
Cc: Jake <jforst.mailman@HIDDEN>, 74912 <at> debbugs.gnu.org,
 Tomas Volf <~@wolfsden.cz>, 76998-done <at> debbugs.gnu.org,
 Daniel Littlewood <dan@HIDDEN>
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: -0.3 (/)

Hi,

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

> So shepherd will now refuse to start when it determines that an instance
> is already listening on its socket:
>
>   https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=3D787d5a33aea=
061b5052faa0863c96be722440ce3

This commit is in 1.0.4.  Closing!

Ludo=E2=80=99.




Notification sent to Jake <jforst.mailman@HIDDEN>:
bug acknowledged by developer. Full text available.
Reply sent to Ludovic Courtès <ludo@HIDDEN>:
You have taken responsibility. Full text available.

Message received at 76998-done <at> debbugs.gnu.org:


Received: (at 76998-done) by debbugs.gnu.org; 14 May 2025 17:04:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 13:04:08 2025
Received: from localhost ([127.0.0.1]:44765 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uFFWZ-0004oD-UN
	for submit <at> debbugs.gnu.org; Wed, 14 May 2025 13:04:08 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:37298)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>)
 id 1uFFWR-0004m8-U2; Wed, 14 May 2025 13:04:02 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 051E0E30;
 Wed, 14 May 2025 19:03:54 +0200 (CEST)
X-Virus-Scanned: Debian amavis at hera.aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavis, port 10024) with ESMTP
 id Ev7yrxHP5FOJ; Wed, 14 May 2025 19:03:53 +0200 (CEST)
Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 4472BD96;
 Wed, 14 May 2025 19:03:53 +0200 (CEST)
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Danny Milosavljevic <dannym@HIDDEN>
Subject: Re: bug#76998: Guix Home leaves user shepherd on logout, starts new
 instance on login
In-Reply-To: <874iyrkvx7.fsf@HIDDEN> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
 =?utf-8?Q?s?= message of "Mon, 14 Apr 2025 10:08:04 +0200")
References: <871pukdlyo.fsf@HIDDEN> <874iyrkvx7.fsf@HIDDEN>
Date: Wed, 14 May 2025 18:06:11 +0200
Message-ID: <87tt5nyy6k.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
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 76998-done
Cc: Jake <jforst.mailman@HIDDEN>, 74912 <at> debbugs.gnu.org,
 Tomas Volf <~@wolfsden.cz>, 76998-done <at> debbugs.gnu.org,
 Daniel Littlewood <dan@HIDDEN>
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: -0.3 (/)

Hi,

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

> So shepherd will now refuse to start when it determines that an instance
> is already listening on its socket:
>
>   https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=3D787d5a33aea=
061b5052faa0863c96be722440ce3

This commit is in 1.0.4.  Closing!

Ludo=E2=80=99.




Notification sent to xeji@HIDDEN:
bug acknowledged by developer. Full text available.
Reply sent to Ludovic Courtès <ludo@HIDDEN>:
You have taken responsibility. Full text available.

Message received at 76998-done <at> debbugs.gnu.org:


Received: (at 76998-done) by debbugs.gnu.org; 14 May 2025 17:04:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 13:04:08 2025
Received: from localhost ([127.0.0.1]:44765 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uFFWZ-0004oD-UN
	for submit <at> debbugs.gnu.org; Wed, 14 May 2025 13:04:08 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:37298)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>)
 id 1uFFWR-0004m8-U2; Wed, 14 May 2025 13:04:02 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 051E0E30;
 Wed, 14 May 2025 19:03:54 +0200 (CEST)
X-Virus-Scanned: Debian amavis at hera.aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavis, port 10024) with ESMTP
 id Ev7yrxHP5FOJ; Wed, 14 May 2025 19:03:53 +0200 (CEST)
Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 4472BD96;
 Wed, 14 May 2025 19:03:53 +0200 (CEST)
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Danny Milosavljevic <dannym@HIDDEN>
Subject: Re: bug#76998: Guix Home leaves user shepherd on logout, starts new
 instance on login
In-Reply-To: <874iyrkvx7.fsf@HIDDEN> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
 =?utf-8?Q?s?= message of "Mon, 14 Apr 2025 10:08:04 +0200")
References: <871pukdlyo.fsf@HIDDEN> <874iyrkvx7.fsf@HIDDEN>
Date: Wed, 14 May 2025 18:06:11 +0200
Message-ID: <87tt5nyy6k.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
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 76998-done
Cc: Jake <jforst.mailman@HIDDEN>, 74912 <at> debbugs.gnu.org,
 Tomas Volf <~@wolfsden.cz>, 76998-done <at> debbugs.gnu.org,
 Daniel Littlewood <dan@HIDDEN>
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: -0.3 (/)

Hi,

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

> So shepherd will now refuse to start when it determines that an instance
> is already listening on its socket:
>
>   https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=3D787d5a33aea=
061b5052faa0863c96be722440ce3

This commit is in 1.0.4.  Closing!

Ludo=E2=80=99.




Notification sent to dannym@HIDDEN:
bug acknowledged by developer. Full text available.
Reply sent to Ludovic Courtès <ludo@HIDDEN>:
You have taken responsibility. Full text available.
Changed bug title to 'Guix Home leaves user shepherd on logout, starts new instance on login' from 'user shepherd stays around with some zombies' Request was from Ludovic Courtès <ludo@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
Merged 67863 74912 76998. Request was from Ludovic Courtès <ludo@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
Severity set to 'important' from 'normal' Request was from Ludovic Courtès <ludo@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 76998 <at> debbugs.gnu.org:


Received: (at 76998) by debbugs.gnu.org; 13 Mar 2025 22:49:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 18:49:11 2025
Received: from localhost ([127.0.0.1]:58767 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tsrMU-0003gP-JD
	for submit <at> debbugs.gnu.org; Thu, 13 Mar 2025 18:49:11 -0400
Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:42229)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <jforst.mailman@HIDDEN>)
 id 1tsrMR-0003fi-27
 for 76998 <at> debbugs.gnu.org; Thu, 13 Mar 2025 18:49:07 -0400
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3913d129c1aso1230449f8f.0
 for <76998 <at> debbugs.gnu.org>; Thu, 13 Mar 2025 15:49:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1741906141; x=1742510941; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=nZLdGE6K1E8CMFA1o+ZqBXQAiZK7OgfLesajHPeO9KU=;
 b=biOKRJOa9sdoyUVgsuX/MJjqBo6hFSy3rL/2gbqajsZbBrV3bB4b1ilztIWg72nMPu
 yrrmogwt7KK0XaP1hyyuEjtjTD3CPkehYBZg4b0weQndnbKYhkKmlKdQRQxufOk0l1UQ
 Z/xq30KgMTnkrcniTjhQeysiYTkM5TBZVrSJ0fk9auCaq1dgq98JsQT1gUY+ltn7Vgol
 +BVvaNyOu5+/aO00gvBTQt80cJ+buuPYke+bsgixJ+hkeiYeIxiH3hchsMQ/KBPCh6Ef
 hAgYzWn2MbrEN+LomeVTZtWEHGOcfl2be2FvHgLobV96Fsf0RQM9VaIbXFI1x5HD4mfy
 j+zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1741906141; x=1742510941;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=nZLdGE6K1E8CMFA1o+ZqBXQAiZK7OgfLesajHPeO9KU=;
 b=GHsv92w5s1K/vbt6LnaEizvrB1BuVJIyYP4E3FCortfyZgdC4tK9Xnt455Wd3xdT+C
 R3UD7oafIgef9Ctyif0LqJZN1NGNdolrwGtbAa24KEKzOiIR6q4sZuYj4jxSbLC7zTbB
 kWay5uRiey2Mmlsmi2AdZ6KRWNdtOkssR4jFUTWui0fNq3YTytu+c0nzDc9Br4idihvg
 G8CtE9ozxyj60orJLK4Ifp8QFZxH+40KGo4yCDS7U60dpyS9ySw9zsxWJM1W8d0U8v6X
 w2msIFi/kPHD7ChLN45ZzcZfKC3lD+uSqe2htp1HwrKgmLE9urjdfx7HvOqysHAZCo6m
 JT/Q==
X-Gm-Message-State: AOJu0YyEZoGcZzyNu0MYeDS6Oi+GKuJEAq0uaLiGDBm7UkxmsMeO3cjK
 58gucAG7J8YeSXKBNE3Ke7mrVSfm7DmvuHkN1XVhLmNJGkayVstvgWwVEMpqnXmgEiBaJpJG2/G
 1eail4R67ggN3rJKH21wjR0w8pjLjSg==
X-Gm-Gg: ASbGncs+jsTcLgmMSXKTQzrCtN8PU58MRAmQ9ypknLqpHbc/WjmWsLyPZC8jQZ3sGmR
 YTrkgQOQcKSy2HbUo7f2hgdrEm/JRcltGzoGEPTqTclxPbGt2ajz1XCXcvaQY81aLOumBYkdK/m
 BPm4LSeE2FU6Xe6Ap3MJ2AKHpJwdJhGeuTvGUKvgRvLeAzngA1RVrYP0oPiug=
X-Google-Smtp-Source: AGHT+IElFtpThijq9RJJPPnffNSqzIAScJAoDfZLAIyx5vKuL/PTHFPzKfrRTyJnV86ykxZHN3qXKOi0oLJf+tGCsbE=
X-Received: by 2002:a05:6000:1789:b0:38f:4ffd:c757 with SMTP id
 ffacd0b85a97d-3971b9f6bb5mr175001f8f.2.1741906140380; Thu, 13 Mar 2025
 15:49:00 -0700 (PDT)
MIME-Version: 1.0
References: <fc9ad8bb0188a074005a1eb1648cb755@HIDDEN>
In-Reply-To: <fc9ad8bb0188a074005a1eb1648cb755@HIDDEN>
From: Jake <jforst.mailman@HIDDEN>
Date: Fri, 14 Mar 2025 09:18:49 +1030
X-Gm-Features: AQ5f1JoJW5LtC600fknLHYOrwibhmvFjxeeuOpfMeUiHONZPnEFExgzyG9LN36g
Message-ID: <CAJqVjv8HTo0HxkyEVP94w1bWCyGvXP2HmURdHM1Bd_mY0wKBYw@HIDDEN>
Subject: Re: bug#76998: user shepherd stays around with some zombies
To: dannym@HIDDEN
Content-Type: multipart/alternative; boundary="000000000000bac56706304120fc"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 76998
Cc: 76998 <at> debbugs.gnu.org
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.0 (-)

--000000000000bac56706304120fc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Is this the same as
https://issues.guix.gnu.org/74912
?

Jake

On Fri, 14 Mar 2025 at 5:41=E2=80=AFam, <dannym@HIDDEN> wrot=
e:

> Steps to reproduce:
>
> 1. Log into the console using your regular user
> 2. Log into GUI using your regular user
> 3. Log out of GUI
> 4. Switch to logged-in console
> 5. Run "px --tree" there
> 6. Observe the following:
>
> shepherd(1)
>    accounts-daemon(1110)
>    avahi-daemon:(2443)
>      avahi-daemon:(2446)
>    bluetoothd(1026)
>    colord(25587)
>    cupsd(2440)
>    dbus-daemon(769)
>    dnsmasq(1845)
>      dnsmasq(1846)
>    earlyoom(744)
>    elogind(1024)
>    gdm(1038)
>    guix-daemon(740)
>    libvirtd(1023)
>    login(26536)
>      -bash(6739)
>    mcron(747)
>    mingetty... (5=C3=97)
>    ModemManager(1276)
>    NetworkManager(1256)
>    nginx:(797)
>      nginx:(798)
>    nscd(2177)
>    polkitd(1231)
>    postgres(852)
>      postgres:... (6=C3=97)
>    rasdaemon(796)
>    rpc.idmapd(2447)
>    rpc.mountd(2501)
>    rpc.statd(2444)
>    rpcbind(2441)
>    shepherd(6395) <--- also dannym
>      [dbus-daemon](6397)
>      [ssh-agent](6444)
>      [xdg-permission-](6411)
>      wireplumber(6399)
>    shepherd(26114) <--- dannym
>      dbus-daemon(6881)
>      pipewire(6882)
>      pipewire-pulse(6883)
>      ssh-agent(6880)
>      wireplumber(6888)
>      xdg-permission-store(7259)
>    udevd(330)
>    upowerd(1025)
>    virtlogd(742)
>    wpa_supplicant(1045)
>
> Those "[...]" with brackets mean that these processes were not reaped
> (so is defunct).
>
> What the hell?
>
> $ guix describe
> Generation 194  Mar 13 2025 19:11:33    (current)
>    guix 678b3dd
>      repository URL: https://git.savannah.gnu.org/git/guix.git
>      branch: master
>      commit: 678b3dddfe442e643fe5cff7730d4f9690c3e2c2
>
>
>
>

--000000000000bac56706304120fc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Is this the same as=C2=A0</div><div dir=3D"auto"><a href=
=3D"https://issues.guix.gnu.org/74912">https://issues.guix.gnu.org/74912</a=
><br>?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Jake</div><div di=
r=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quot=
e_container" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 14 =
Mar 2025 at 5:41=E2=80=AFam, &lt;<a href=3D"mailto:dannym@friendly-machines=
.com">dannym@HIDDEN</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"=
>Steps to reproduce:<br>
<br>
1. Log into the console using your regular user<br>
2. Log into GUI using your regular user<br>
3. Log out of GUI<br>
4. Switch to logged-in console<br>
5. Run &quot;px --tree&quot; there<br>
6. Observe the following:<br>
<br>
shepherd(1)<br>
=C2=A0 =C2=A0accounts-daemon(1110)<br>
=C2=A0 =C2=A0avahi-daemon:(2443)<br>
=C2=A0 =C2=A0 =C2=A0avahi-daemon:(2446)<br>
=C2=A0 =C2=A0bluetoothd(1026)<br>
=C2=A0 =C2=A0colord(25587)<br>
=C2=A0 =C2=A0cupsd(2440)<br>
=C2=A0 =C2=A0dbus-daemon(769)<br>
=C2=A0 =C2=A0dnsmasq(1845)<br>
=C2=A0 =C2=A0 =C2=A0dnsmasq(1846)<br>
=C2=A0 =C2=A0earlyoom(744)<br>
=C2=A0 =C2=A0elogind(1024)<br>
=C2=A0 =C2=A0gdm(1038)<br>
=C2=A0 =C2=A0guix-daemon(740)<br>
=C2=A0 =C2=A0libvirtd(1023)<br>
=C2=A0 =C2=A0login(26536)<br>
=C2=A0 =C2=A0 =C2=A0-bash(6739)<br>
=C2=A0 =C2=A0mcron(747)<br>
=C2=A0 =C2=A0mingetty... (5=C3=97)<br>
=C2=A0 =C2=A0ModemManager(1276)<br>
=C2=A0 =C2=A0NetworkManager(1256)<br>
=C2=A0 =C2=A0nginx:(797)<br>
=C2=A0 =C2=A0 =C2=A0nginx:(798)<br>
=C2=A0 =C2=A0nscd(2177)<br>
=C2=A0 =C2=A0polkitd(1231)<br>
=C2=A0 =C2=A0postgres(852)<br>
=C2=A0 =C2=A0 =C2=A0postgres:... (6=C3=97)<br>
=C2=A0 =C2=A0rasdaemon(796)<br>
=C2=A0 =C2=A0rpc.idmapd(2447)<br>
=C2=A0 =C2=A0rpc.mountd(2501)<br>
=C2=A0 =C2=A0rpc.statd(2444)<br>
=C2=A0 =C2=A0rpcbind(2441)<br>
=C2=A0 =C2=A0shepherd(6395) &lt;--- also dannym<br>
=C2=A0 =C2=A0 =C2=A0[dbus-daemon](6397)<br>
=C2=A0 =C2=A0 =C2=A0[ssh-agent](6444)<br>
=C2=A0 =C2=A0 =C2=A0[xdg-permission-](6411)<br>
=C2=A0 =C2=A0 =C2=A0wireplumber(6399)<br>
=C2=A0 =C2=A0shepherd(26114) &lt;--- dannym<br>
=C2=A0 =C2=A0 =C2=A0dbus-daemon(6881)<br>
=C2=A0 =C2=A0 =C2=A0pipewire(6882)<br>
=C2=A0 =C2=A0 =C2=A0pipewire-pulse(6883)<br>
=C2=A0 =C2=A0 =C2=A0ssh-agent(6880)<br>
=C2=A0 =C2=A0 =C2=A0wireplumber(6888)<br>
=C2=A0 =C2=A0 =C2=A0xdg-permission-store(7259)<br>
=C2=A0 =C2=A0udevd(330)<br>
=C2=A0 =C2=A0upowerd(1025)<br>
=C2=A0 =C2=A0virtlogd(742)<br>
=C2=A0 =C2=A0wpa_supplicant(1045)<br>
<br>
Those &quot;[...]&quot; with brackets mean that these processes were not re=
aped <br>
(so is defunct).<br>
<br>
What the hell?<br>
<br>
$ guix describe<br>
Generation 194=C2=A0 Mar 13 2025 19:11:33=C2=A0 =C2=A0 (current)<br>
=C2=A0 =C2=A0guix 678b3dd<br>
=C2=A0 =C2=A0 =C2=A0repository URL: <a href=3D"https://git.savannah.gnu.org=
/git/guix.git" rel=3D"noreferrer" target=3D"_blank">https://git.savannah.gn=
u.org/git/guix.git</a><br>
=C2=A0 =C2=A0 =C2=A0branch: master<br>
=C2=A0 =C2=A0 =C2=A0commit: 678b3dddfe442e643fe5cff7730d4f9690c3e2c2<br>
<br>
<br>
<br>
</blockquote></div></div>

--000000000000bac56706304120fc--




Information forwarded to bug-guix@HIDDEN:
bug#76998; Package guix. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 13 Mar 2025 19:10:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 13 15:10:54 2025
Received: from localhost ([127.0.0.1]:58160 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tsnxG-0007F3-GM
	for submit <at> debbugs.gnu.org; Thu, 13 Mar 2025 15:10:54 -0400
Received: from lists.gnu.org ([2001:470:142::17]:46602)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <dannym@HIDDEN>)
 id 1tsnxD-0007EY-RM
 for submit <at> debbugs.gnu.org; Thu, 13 Mar 2025 15:10:52 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <dannym@HIDDEN>)
 id 1tsnx2-0000AT-N2
 for bug-guix@HIDDEN; Thu, 13 Mar 2025 15:10:42 -0400
Received: from shrimp.cherry.relay.mailchannels.net ([23.83.223.164])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <dannym@HIDDEN>)
 id 1tsnx0-0007fB-SC
 for bug-guix@HIDDEN; Thu, 13 Mar 2025 15:10:40 -0400
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
Received: from relay.mailchannels.net (localhost [127.0.0.1])
 by relay.mailchannels.net (Postfix) with ESMTP id A301A18227D
 for <bug-guix@HIDDEN>; Thu, 13 Mar 2025 19:10:36 +0000 (UTC)
Received: from pdx1-sub0-mail-a308.dreamhost.com
 (100-110-242-246.trex-nlb.outbound.svc.cluster.local [100.110.242.246])
 (Authenticated sender: dreamhost)
 by relay.mailchannels.net (Postfix) with ESMTPA id 3C3CF182843
 for <bug-guix@HIDDEN>; Thu, 13 Mar 2025 19:10:36 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1741893036; a=rsa-sha256;
 cv=none;
 b=gsoLYV4GE4msBz0n2U3ZCtpSnBsWIp0BuR0BcQwSqNFb0QLr2fkeC6Yh77FcaTMa3PcXyg
 gybmso9nUkkcBJ4HTdBABinsKrgZ3eOC/J4f6es9y6/q445E+y6rsRqyKjT5yJAkXBHQWN
 ioLIgS5OBZwHRxioBk4v6QotT+qF7Kv/NhNroOeymx3jvNLf9U7k8xUGouHqg1A6++5f6d
 Rg6H7UTVXIt64Cysuhc6xgIFcid5+y83hKpTPD3tjk7DVASW68V4vuSuvF3srWe8B3mxAE
 HEdXgT1V3jSTKT5U7CU+RfbUZMmlPGxXEVIG4MmC+M0Oj7SOmZDJkVEjDVsoJA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
 d=mailchannels.net; s=arc-2022; t=1741893036;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:dkim-signature;
 bh=1k6pVmqwPJvW0IPDoJ8RYqbBfoKt0itbLhPERd6ietg=;
 b=AEChMarVV713u8Y2IhZmfRcERzNPe+vepO49TJ0X1zc9DUurVdVJ1nu4B/SQW9hpxzqFQf
 oan37OAv7MSvIJ0JMuTz71o4pkRDyop/BK+WmuL4c9DVnWYz6A30MN4kngDvasNafj5+Qt
 zG50EHBjapOqyA8zlSFQTDi7id+QeDq6Kqe64W5T/nxwYs/mom/Ys80CeVRIYEDj6y1j5i
 /nUejaKtpnnOVRdO7FDa5LWDH0EOR+ol+Dk//5RiH5rULoyf2svEalxQt+1W0N4j0fXG5k
 99f8jQKNT0m9L+OfnupPXQzcFDC7ts/jIeVG4TMKbG51j7M1EkTfaXdBX1QvEQ==
ARC-Authentication-Results: i=1; rspamd-5f7c79bbc7-jbs49;
 auth=pass smtp.auth=dreamhost smtp.mailfrom=dannym@HIDDEN
X-Sender-Id: dreamhost|x-authsender|dannym@HIDDEN
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|dannym@HIDDEN
X-MailChannels-Auth-Id: dreamhost
X-Little-Invention: 77a0d0e43cc56b2d_1741893036454_3570281029
X-MC-Loop-Signature: 1741893036454:3335984324
X-MC-Ingress-Time: 1741893036454
Received: from pdx1-sub0-mail-a308.dreamhost.com (pop.dreamhost.com
 [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)
 by 100.110.242.246 (trex/7.0.2); Thu, 13 Mar 2025 19:10:36 +0000
Received: from webmail.friendly-machines.com (ip-66-33-200-4.dreamhost.com
 [66.33.200.4]) (Authenticated sender: dannym@HIDDEN)
 by pdx1-sub0-mail-a308.dreamhost.com (Postfix) with ESMTPA id 4ZDHC00y8zz3B
 for <bug-guix@HIDDEN>; Thu, 13 Mar 2025 12:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=friendly-machines.com; s=dreamhost; t=1741893036;
 bh=1k6pVmqwPJvW0IPDoJ8RYqbBfoKt0itbLhPERd6ietg=;
 h=Date:From:To:Subject:Content-Type:Content-Transfer-Encoding;
 b=M1z27lr9qV0ytGK4ixKiV6zfrkvIsdHcfSUxjtwxC97XIsvzjU6Sqj6Aq65PPcvQI
 HkvLdTfMWVKdpPTtjq+e96vnu6EkCrFw+s5Zy7NPznND6ar/hrfPmPMSoiXeucu4U0
 ko2MglcJPJb2PiIkZThoNTN8aw2fX10PtOd9ar28v+DOpVbBRngSYglg38KUejTmB1
 TmE+yRD2XRyxInF/R7kjf3Wwp6X6sfcz68DpcYRcyxhSzVECj47J4pKNRuyra+DiUi
 858FMEOqkEus+FaofpryIvbcchG1U/NvrkNuoosUNlNF1Y09kvHYD2IpKBlwIJZ6qH
 s5cP8zKo3LA5w==
MIME-Version: 1.0
Date: Thu, 13 Mar 2025 20:10:36 +0100
From: dannym@HIDDEN
To: Bug Guix <bug-guix@HIDDEN>
Subject: user shepherd stays around with some zombies
User-Agent: Roundcube Webmail/1.5.0
Message-ID: <fc9ad8bb0188a074005a1eb1648cb755@HIDDEN>
X-Sender: dannym@HIDDEN
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=23.83.223.164;
 envelope-from=dannym@HIDDEN;
 helo=shrimp.cherry.relay.mailchannels.net
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 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,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
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: -0.1 (/)

Steps to reproduce:

1. Log into the console using your regular user
2. Log into GUI using your regular user
3. Log out of GUI
4. Switch to logged-in console
5. Run "px --tree" there
6. Observe the following:

shepherd(1)
   accounts-daemon(1110)
   avahi-daemon:(2443)
     avahi-daemon:(2446)
   bluetoothd(1026)
   colord(25587)
   cupsd(2440)
   dbus-daemon(769)
   dnsmasq(1845)
     dnsmasq(1846)
   earlyoom(744)
   elogind(1024)
   gdm(1038)
   guix-daemon(740)
   libvirtd(1023)
   login(26536)
     -bash(6739)
   mcron(747)
   mingetty... (5×)
   ModemManager(1276)
   NetworkManager(1256)
   nginx:(797)
     nginx:(798)
   nscd(2177)
   polkitd(1231)
   postgres(852)
     postgres:... (6×)
   rasdaemon(796)
   rpc.idmapd(2447)
   rpc.mountd(2501)
   rpc.statd(2444)
   rpcbind(2441)
   shepherd(6395) <--- also dannym
     [dbus-daemon](6397)
     [ssh-agent](6444)
     [xdg-permission-](6411)
     wireplumber(6399)
   shepherd(26114) <--- dannym
     dbus-daemon(6881)
     pipewire(6882)
     pipewire-pulse(6883)
     ssh-agent(6880)
     wireplumber(6888)
     xdg-permission-store(7259)
   udevd(330)
   upowerd(1025)
   virtlogd(742)
   wpa_supplicant(1045)

Those "[...]" with brackets mean that these processes were not reaped 
(so is defunct).

What the hell?

$ guix describe
Generation 194	Mar 13 2025 19:11:33	(current)
   guix 678b3dd
     repository URL: https://git.savannah.gnu.org/git/guix.git
     branch: master
     commit: 678b3dddfe442e643fe5cff7730d4f9690c3e2c2




Acknowledgement sent to dannym@HIDDEN:
New bug report received and forwarded. Copy sent to bug-guix@HIDDEN. Full text available.
Report forwarded to bug-guix@HIDDEN:
bug#76998; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 18 May 2025 12:45:02 UTC

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