GNU logs - #65463, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
Resent-From: Tanguy LE CARROUR <tanguy@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 23 Aug 2023 06:48:02 +0000
Resent-Message-ID: <handler.65463.B.169277325716125 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 65463 <at> debbugs.gnu.org
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: Tanguy LE CARROUR <tanguy@HIDDEN>
Date: Wed, 23 Aug 2023 08:47:13 +0200
Message-ID: <169277323322.1687.15739147838600524142@localhost>
User-Agent: alot/0.10
Received-SPF: pass client-ip=2001:1600:4:17::42ae;
 envelope-from=tanguy@HIDDEN; helo=smtp-42ae.mail.infomaniak.ch
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 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_LOW=-0.7, 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-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 (/)

Hi Guix,

I think this has been happening for quite a long time, but I never paid
attention to it, for everything seemed to be running just fine.
When I run `guix home reconfigure`, it completes with the following message:

```
# [=E2=80=A6]
Finished updating symlinks.

SSLoading /gnu/store/zbfyaxxigns5lqyxhxzxhm92w54ns1cz-shepherd.conf.
herd: error: exception caught while executing 'load' on service 'root':
In procedure fport_write: Broken pipe
Comparing /gnu/store/2sr90smj33k686394krjx1klhlpipd7z-home/profile/share/fo=
nts and
          /gnu/store/2sr90smj33k686394krjx1klhlpipd7z-home/profile/share/fo=
nts... done (same)
Evaluating on-change gexps.

On-change gexps evaluation finished.
```

I don't know if it's related, but since my last `guix pull`,
`herd status` has been reporting strange statuses:

```
$ herd status
Started:
 + root
Starting:
 ^ mcron
 ^ mpd
Stopped:
 - tor
 - transmission
```

`mcron` and `mpd` (a home service that I will eventually submit) are listed=
 as
`starting`, but they are actually started and they work just fine!?

I had a look at this morning's log. This is what I see right after logging =
in:

```
2023-08-23 08:21:36 Starting service root...
2023-08-23 08:21:36 Service root started.
2023-08-23 08:21:36 Service root running with value #t.
2023-08-23 08:21:36 Service root has been started.
2023-08-23 08:21:36 Daemonizing...
2023-08-23 08:21:36 Restarting signal handler.
2023-08-23 08:21:36 Now running as process 567.
2023-08-23 08:21:36 Starting services...
2023-08-23 08:21:36 Configuration successfully loaded from '/gnu/store/zbfy=
axxigns5lqyxhxzxhm92w54ns1cz-shepherd.conf'.
2023-08-23 08:21:36 Starting service mpd...
2023-08-23 08:21:36 Starting service mcron...
2023-08-23 08:21:36 Service mpd has been started.
2023-08-23 08:21:37 [mpd] Aug 23 08:21 : server_socket: bind to '0.0.0.0:66=
00' failed (continuing anyway, because binding to '[::]:6600' succeeded): F=
ailed to bind socket: Address already in use
```

The last line is strange. It looks like a second instance of `mpd`
started, tried to bind to the same port and failed!?

After `guix home reconfigure` I get:

```
2023-08-23 08:31:51 Service mcron has been started.
2023-08-23 08:31:51 SSL2023-08-23 08:31:51 oading /gnu/store/zbfyaxxigns5lq=
yxhxzxhm92w54ns1cz-shepherd.conf.
```

There is no mention to `mpd` and there's a timestamp right in the middle of
the second line?!

When I try to `herd stop SOMETHING`, it hangs forever and I have to
`ctrl+c` it.

Any idea what might be going wrong?!

--=20
Tanguy

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Tanguy LE CARROUR <tanguy@HIDDEN>
Subject: bug#65463: Acknowledgement (Herd `fport_write: Broken pipe` error
 when running `guix home reconfigure`)
Message-ID: <handler.65463.B.169277325716125.ack <at> debbugs.gnu.org>
References: <169277323322.1687.15739147838600524142@localhost>
X-Gnu-PR-Message: ack 65463
X-Gnu-PR-Package: guix
Reply-To: 65463 <at> debbugs.gnu.org
Date: Wed, 23 Aug 2023 06:48:02 +0000

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

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

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

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

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

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

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

Message sent to bug-guix@HIDDEN:

Subject: bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
References: <169277323322.1687.15739147838600524142@localhost>
In-Reply-To: <169277323322.1687.15739147838600524142@localhost>
Resent-From: Elias Kueny <elias.kueny@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 09 Sep 2023 16:12:02 +0000
Resent-Message-ID: <handler.65463.B65463.16942758682604 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 65463 <at> debbugs.gnu.org
From: Elias Kueny <elias.kueny@HIDDEN>
Date: Sat, 09 Sep 2023 16:09:46 +0000
Message-ID: <87sf7nfhtf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

I experience the same thing. I hadn't updated guix since may (last generati=
on was commit 91bfd30ee3f35dfb7048bf42aea92f939cffbf17), and since I did I'=
m encountering issues with shepherd.

Probably unrelated, but for the record: my first issue was caused by the di=
sappearance of the XDG_LOG_HOME environment variable. I was using it in the=
 definition of shepherd services (as for example `#:log-file (string-append=
 (getenv "XDG_LOG_HOME") "/emacs-daemon.log")`. Guix home reconfigure worke=
d because the getenv wasn't evaluated immediately, but after a reboot the s=
yntax error prevented shepherd to start the session.

But once I solved that, same problems: shepherd seems to hang somewhere aft=
er starting the home services.

herd status:
--8<---------------cut here---------------start------------->8---
Started:
 + root
Starting:
 ^ emacs-daemon
 ^ ssh-agent
 ^ syncthing
--8<---------------cut here---------------end--------------->8---

~/.local/state/log/shepherd.log:
--8<---------------cut here---------------start------------->8---
2023-09-09 16:12:42 Service root started.
2023-09-09 16:12:42 Service root running with value #t.
2023-09-09 16:12:42 Service root has been started.
2023-09-09 16:12:42 Daemonizing...
2023-09-09 16:12:42 Restarting signal handler.
2023-09-09 16:12:42 Now running as process 430.
2023-09-09 16:12:42 Starting services...
2023-09-09 16:12:42 Configuration successfully loaded from '/gnu/store/mq01=
z0gvi1zv3skk6xh1q7g4id6hsgdk-shepherd.conf'.
2023-09-09 16:12:42 Starting service ssh-agent...
2023-09-09 16:12:42 Starting service syncthing...
2023-09-09 16:12:42 Starting service emacs-daemon...
2023-09-09 16:12:42 Service ssh-agent has been started.
2023-09-09 16:12:42 Service syncthing has been started.
--- guix home reconfigure happened here ---
2023-09-09 16:59:00 Service emacs-daemon has been started.
2023-09-09 16:59:00 SSSL2023-09-09 16:59:00 oading /gnu/store/mlvqhkb37zy3y=
ycriv3lmqah7yff34af-shepherd.conf.
--8<---------------cut here---------------end--------------->8---

My 3 services are working normally. If I try to run `herd restart emacs-dae=
mon`, the command hangs until I press Ctrl-C and nothing happens to emacs. =
Same thing for the other services (and for `herd stop`).

Here's how my services are defined. If I comment out all occurrences of `ho=
me-shepherd-service-type` in my home configuration (not just commenting %em=
acs-daemon-user-service and running it with an empty list of services), the=
n there is no error when running `guix home reconfigure`.

--8<---------------cut here---------------start------------->8---
(define %emacs-daemon-user-service
  (shepherd-service
   (documentation "Run emacs-daemon.")
   (provision '(emacs-daemon))
   (start #~(make-forkexec-constructor
             (list #$(file-append (specification->package %emacs-package) "=
/bin/emacs") "--fg-daemon")
             #:log-file (string-append #$(getenv "HOME") "/.local/var/log/e=
macs-daemon.log")))
   (stop #~(make-system-destructor "emacsclient --eval \"(kill-emacs)\""))
   (auto-start? #t)
   (respawn? #t)))

(define-public emacs-services
  (list (simple-service 'emacs-shepherd-service
                         home-shepherd-service-type
                         (list %emacs-daemon-user-service))))

(home-environment (services `(,@emacs-services [=E2=80=A6])))
--8<---------------cut here---------------end--------------->8---

When reconfiguring with an home-shepherd-service-type service but not sheph=
erd service in the list:

--8<---------------cut here---------------start------------->8---
Finished updating symlinks.

Loading /gnu/store/26jgrxzmabjdl3nhjx16cqa1f5h3flks-shepherd.conf.
herd: error: exception caught while executing 'load' on service 'root':
In procedure fport_write: Broken pipe
Comparing /gnu/store/4vmxyl8fykz9wkrkicnv5azhvr1gb5i1-home/profile/share/fo=
nts and
          /gnu/store/3wlqdh4i4zmwjmqa69isr62nvbgf7abh-home/profile/share/fo=
nts... done (same)
Comparing /gnu/store/4vmxyl8fykz9wkrkicnv5azhvr1gb5i1-home/files/.config/fi=
sh/fish_plugins and
          /gnu/store/3wlqdh4i4zmwjmqa69isr62nvbgf7abh-home/files/.config/fi=
sh/fish_plugins... done (same)
Evaluating on-change gexps.

On-change gexps evaluation finished.
--8<---------------cut here---------------end--------------->8---

Only new line in ~/.local/state/log/shepherd.log:
--8<---------------cut here---------------start------------->8---
2023-09-09 17:45:07 Loading /gnu/store/26jgrxzmabjdl3nhjx16cqa1f5h3flks-she=
pherd.conf.
--8<---------------cut here---------------end--------------->8---

/gnu/store/26jgrxzmabjdl3nhjx16cqa1f5h3flks-shepherd.conf:
--8<---------------cut here---------------start------------->8---
(begin (use-modules (srfi srfi-34) (system repl error-handling)) (apply reg=
ister-services (map (lambda (file) (load file)) (quote ()))) (action (quote=
 root) (quote daemonize)) (format #t "Starting services...~%") (let ((servi=
ces-to-start (quote ()))) (if (defined? (quote start-in-the-background)) (s=
tart-in-the-background services-to-start) (for-each start services-to-start=
)) (redirect-port (open-input-file "/dev/null") (current-input-port))))
--8<---------------cut here---------------end--------------->8---

So I would guess it's a problem in home-shepherd-service-type, and not in t=
he custom service definitions. I also remember the broken pipe error showin=
g previously, but shepherd commands hanging is new.

Message sent to bug-guix@HIDDEN:

Subject: bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
References: <169277323322.1687.15739147838600524142@localhost>
In-Reply-To: <169277323322.1687.15739147838600524142@localhost>
Resent-From: richard@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 15 Nov 2023 01:58:09 +0000
Resent-Message-ID: <handler.65463.B65463.170001347728583 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 65463 <at> debbugs.gnu.org
MIME-Version: 1.0
Date: Tue, 14 Nov 2023 20:55:26 -0500
From: richard@HIDDEN
Message-ID: <87107ca490c719dd1e9c7a75915ceaa8@HIDDEN>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Just throwing out that I'm also experiencing this issue, even with a 
home configuration containing a single service, that being 
home-gpg-agent-service. I've deployed the same configuration on two 
different machines at the same checkout and only experience the issue on 
one. The other machine works flawlessly. The only distinction between 
the two is that the working machine is using Guix on a foreign 
distribution while the nonworking machine is using Guix System.

I do see the same behavior mentioned previously such as herd commands 
hanging. However, in my case there seems to be another negative symptom 
from shepherd acting this way.

Various $ gpg commands will hang (presumably when they try invoking 
gpg-agent). Trying to manually invoke $ gpg-agent --daemon fails and 
hangs indefinitely without a message. This effectively makes gpg 
unusable.

Barebones home-environment:
--8<---------------cut here---------------start------------->8---
(home-environment
    (services
     (list
      (service home-gpg-agent-service-type
               (home-gpg-agent-configuration
                (pinentry-program
                 (file-append pinentry-tty "/bin/pinentry-tty"))
                (ssh-support? #t))))))
--8<---------------cut here---------------end--------------->8---

herd status:
--8<---------------cut here---------------start------------->8---
Started:
+ gpg-agent
+ root
--8<---------------cut here---------------end--------------->8---

Interestingly when running $ gpg --card-status I see the following 
printed to the log:

shepherd.log (nonworking machine):
--8<---------------cut here---------------start------------->8---
2023-11-14 19:23:06 Spawning systemd-style service 
/gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.
2023-11-14 19:23:06 L2023-11-14 19:23:06 oading 
/gnu/store/kzh1x4y030drw0jrdk08nynvvyasm3c1-shepherd.conf.
--8<---------------cut here---------------end--------------->8---

shepherd.log (working machine):
--8<---------------cut here---------------start------------->8---
2023-11-14 19:43:39 Spawning systemd-style service 
/gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.
2023-11-14 19:43:39 Running value of service gpg-agent changed to 611.
2023-11-14 19:43:39 [gpg-agent] using fd 3 for ssh socket 
(/run/user/1000/gnupg/S.gpg-agent.ssh)
2023-11-14 19:43:39 [gpg-agent] using fd 4 for browser socket 
(/run/user/1000/gnupg/S.gpg-agent.browser)
2023-11-14 19:43:39 [gpg-agent] using fd 5 for extra socket 
(/run/user/1000/gnupg/S.gpg-agent.extra)
2023-11-14 19:43:39 [gpg-agent] using fd 6 for std socket 
(/run/user/1000/gnupg/S.gpg-agent)
2023-11-14 19:43:39 [gpg-agent] listing on: std=6 extra=5 browser=4 
ssh=3)
--8<---------------cut here---------------end--------------->8---

For some reason shepherd is rereading its configuration file instead of 
properly spawning the gpg-agent service. shepherd.conf and 
shepherd-gpg-agent-ssh-agent.scm (a file that appears in shepherd.conf) 
are identical between the two machines.

shepherd.conf (working and nonworking machine):
--8<---------------cut here---------------start------------->8---
(begin (use-modules (srfi srfi-34) (system repl error-handling)) (apply 
register-services (map (lambda (file) (load file)) (quote 
("/gnu/store/6zcvlihqs5mniw2vly4w7z39lhai2grz-shepherd-gpg-agent-ssh-agent.scm")))) 
(action (quote root) (quote daemonize)) (format #t "Starting 
services...~%") (let ((services-to-start (quote (gpg-agent ssh-agent)))) 
(if (defined? (quote start-in-the-background)) (start-in-the-background 
services-to-start) (for-each start services-to-start)) (redirect-port 
(open-input-file "/dev/null") (current-input-port))))
--8<---------------cut here---------------end--------------->8---

Sorry if this is too much or not helpful! First time on the mailing 
list.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
References: <169277323322.1687.15739147838600524142@localhost>
In-Reply-To: <169277323322.1687.15739147838600524142@localhost>
Resent-From: Richard Sent <richard@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 16 Nov 2023 20:10:02 +0000
Resent-Message-ID: <handler.65463.B65463.170016536320058 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 65463
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: 65463 <at> debbugs.gnu.org
Received: via spool by 65463-submit <at> debbugs.gnu.org id=B65463.170016536320058
          (code B ref 65463); Thu, 16 Nov 2023 20:10:02 +0000
Received: (at 65463) by debbugs.gnu.org; 16 Nov 2023 20:09:23 +0000
Received: from localhost ([127.0.0.1]:44669 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r3ifz-0005DS-4O
	for submit <at> debbugs.gnu.org; Thu, 16 Nov 2023 15:09:23 -0500
Received: from mail-108-mta175.mxroute.com ([136.175.108.175]:33875)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <richard@HIDDEN>) id 1r3ift-0005DF-5w
 for 65463 <at> debbugs.gnu.org; Thu, 16 Nov 2023 15:09:21 -0500
Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com)
 (Authenticated sender: mN4UYu2MZsgR)
 by mail-108-mta175.mxroute.com (ZoneMTA) with ESMTPSA id
 18bd9c088ef000190b.001 for <65463 <at> debbugs.gnu.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 16 Nov 2023 20:09:15 +0000
X-Zone-Loop: 231813f32779144987b667ce6cc3daf4b64fb3d95448
X-Originating-IP: [136.175.111.2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=freakingpenguin.com; s=x; h=Content-Transfer-Encoding:Content-Type:
 Message-ID:Subject:To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=C5M0S8fIwJoUvV9CJLfd0lxcE47mcncyTSq5AwsPEGg=; b=FqdKQX7g2bLqd78BPchIvmQkgB
 bTnqmZtoDN5fAPmmlpCHr1P7GvtPeYl/LYbXZD0ljCu9eEbFNQLp7RDktClNzNkDOSOSUyMxjFF/F
 huCZs4cOBfbQJ0Jq99YA2wcs+dPYn8GjUIxXFZQbAF0/yEkbqJk9QO2zsEN0tALCs5+2VIEBcZyqs
 gTCf2fbuyROb7LNYYU9SX4ouYXolB/Cr8HH+exOKhM09zQr8KIwbGfZnaVhH9N3x8F9UmWUPraihn
 rosTkJ8aF8bLHUd2Ar++a1W0DcNxyK9cCd2ZYTZ0FLsCq+4Q/svMKrQMq/jYZ+hEMYMuI6QCofPle
 ArczWXBQ==;
MIME-Version: 1.0
Date: Thu, 16 Nov 2023 15:09:13 -0500
From: Richard Sent <richard@HIDDEN>
Message-ID: <5538caef3f592a7adc5b75e1cb99a711@HIDDEN>
X-Sender: richard@HIDDEN
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Id: richard@HIDDEN
X-Spam-Score: -0.0 (/)
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 (-)

Did some more testing and I was able to find a workaround for my version 
of this issue, although I don't know if it'll solve it for others. TL;DR 
is I changed my login shell from fish back to bash.

The system configuration for the nonworking machine was using fish 
`(user-account (shell (file-append fish "/bin/fish") ...)`. There seems 
to be some unintended behavior with executing the `on-first-login` 
script in `.profile` using fish.

The stock `config.fish` sources $HOME/.profile, which executes the 
.guix-home/on-first-login script via fenv source $HOME/.profile. Herd 
seems to start up nicely, but somehow stdout for herd winds assigned to 
a pipe without a reader between initialization and spawning gpg-agent.

initialization writes to the logfile just fine regardless of if you're 
using fish or bash:
--8<---------------cut here---------------start------------->8---
2023-11-16 14:17:15 Starting service root...
2023-11-16 14:17:15 Service root started.
2023-11-16 14:17:15 Service root running with value #t.
2023-11-16 14:17:15 Service root has been started.
2023-11-16 14:17:15 Daemonizing...
2023-11-16 14:17:15 Restarting signal handler.
2023-11-16 14:17:15 Now running as process 936.
2023-11-16 14:17:15 Starting services...
2023-11-16 14:17:15 Configuration successfully loaded from 
'/gnu/store/kzh1x4y030drw0jrdk08nynvvyasm3c1-shepherd.conf'.
2023-11-16 14:17:15 Starting service gpg-agent...
2023-11-16 14:17:15 Service gpg-agent has been started.
2023-11-16 14:17:15 Service gpg-agent started.
2023-11-16 14:17:15 Service gpg-agent running with value (("ssh" . 
#<input-output: socket 16>) ("browser" . #<input-output: socket 18>) 
("extra" . #<input-output: socket 19>) ("std" . #<input-output: socket 
20>)).
2023-11-16 14:17:15 Successfully started 2 services in the background.
--8<---------------cut here---------------end--------------->8---

When using bash instead of fish, stdout (file descriptor 1) points to 
/dev/null so the write does not fail. Another write is for 
$HOME/.local/state/shepherd.log.

bash fds
--8<---------------cut here---------------start------------->8---
$ ls -l /proc/<HERD_PID>/fd)
lr-x------   1 richard        users    64 2023-11-16 14:17 0 -> 
/dev/null
l-wx------   1 richard        users    64 2023-11-16 14:17 1 -> 
/dev/null
l-wx------   1 richard        users    64 2023-11-16 15:04 2 -> 
/home/richard/.local/share/sddm/xorg-session.log
l-wx------   1 richard        users    64 2023-11-16 14:17 6 -> 
/home/richard/.local/state/log/shepherd.log
// ...
--8<---------------cut here---------------end--------------->8---

bash login shell strace of herd, right after running $ gpg 
--card-status:
--8<---------------cut here---------------start------------->8---
write(1, "Spawning systemd-style service 
/gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.\n", 
103) = 103
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444, 
st_size=3536, ...}, 0) = 0
write(6, "2023-11-16 14:36:29 Spawning systemd-style service 
/gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.\n", 
123) = 123
// happy success messages
--8<---------------cut here---------------end--------------->8---

However, when fish is in charge of executing on-first-login, stdout and 
stderr for the user shepherd get directed to a pipe instead of 
/dev/null.

fish fds, both stdout and stderr point to a pipe:
--8<---------------cut here---------------start------------->8---
$ ls -l /proc/<HERD_PID>/fd)
lr-x------   1 richard        users    64 2023-11-16 14:47 0 -> 
/dev/null
l-wx------   1 richard        users    64 2023-11-16 14:47 1 -> 
pipe:[41039]
l-wx------   1 richard        users    64 2023-11-16 14:47 2 -> 
pipe:[41039]
l-wx------   1 richard        users    64 2023-11-16 14:47 6 -> 
/home/richard/.local/state/log/shepherd.log
// ...
--8<---------------cut here---------------end--------------->8---

fish login shell strace of herd:
--8<---------------cut here---------------start------------->8---
21:46:43 write(1, "Spawning systemd-style service 
/gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.\n", 
103) = -1 EPIPE (Broken pipe)
--8<---------------cut here---------------end--------------->8---

Details of what processes are using the pipe: (i.e. nothing else is 
using the pipe. Which makes sense for a broken pipe error at least...)
--8<---------------cut here---------------start------------->8---
$ lsof -n | grep -w 41039
(standard input):shepherd   991                   richard    1w     FIFO 
               0,14       0t0     41039 pipe
(standard input):shepherd   991                   richard    2w     FIFO 
               0,14       0t0     41039 pipe
--8<---------------cut here---------------end--------------->8---

What confuses me about this situation is judging from that bash behavior 
pipes shouldn't be involved at all for stdin/stdout/stderr. There's also 
an discrepancy in that stderr for bash points to xorg-session.log while 
for fish it points to the same pipe as stdout. It would be interesting 
to know if other users who are experiencing broken pipe errors are also 
using fish as their user shell.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 20 Mar 2024 18:09:02 +0000
Resent-Message-ID: <handler.65463.B65463.171095812722112 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 65463
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Richard Sent <richard@HIDDEN>
Cc: 65463 <at> debbugs.gnu.org
Received: via spool by 65463-submit <at> debbugs.gnu.org id=B65463.171095812722112
          (code B ref 65463); Wed, 20 Mar 2024 18:09:02 +0000
Received: (at 65463) by debbugs.gnu.org; 20 Mar 2024 18:08:47 +0000
Received: from localhost ([127.0.0.1]:54003 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rn0Mo-0005kT-Pa
	for submit <at> debbugs.gnu.org; Wed, 20 Mar 2024 14:08:47 -0400
Received: from eggs.gnu.org ([209.51.188.92]:55914)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1rn0Mm-0005k6-Pq
 for 65463 <at> debbugs.gnu.org; Wed, 20 Mar 2024 14:08:45 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1rn0M3-0008IF-BO; Wed, 20 Mar 2024 14:07:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=EQO55AA53V5yQWKBnxffDOmd7mCPpwiJlIMdi30LRME=; b=J+Rj+t/k8NiLGRaXNWqH
 wDgntfQ0rmZY9IjKO/z4zGh2Zc+1D7z+rereXTkibhVOPNeUHU50QMC1QcYRFanCfRTaDwFwVcILp
 qtopfMD8yGMlbWegdMNH0PmjzzFvyJm3srNVtLvVYl1xDzGmz+rReN9RsYmAPDDjIzM0IRU/n+90r
 alCl+fyqw+CrBi2uDh0Dyp6wIJvq4rWTipPiXThUe1s0TOufaxKlRqoNqyZb7luirTrx3DmPxn+uL
 YIOngIHaimejtPcboaGHPlV56BrHkCgeZEm818rEx0NIfoOSNUCpzZCHT52RoZAM/FbubVrxmTFta
 o9f9Suzd+53EBw==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <5538caef3f592a7adc5b75e1cb99a711@HIDDEN> (Richard
 Sent's message of "Thu, 16 Nov 2023 15:09:13 -0500")
References: <169277323322.1687.15739147838600524142@localhost>
 <5538caef3f592a7adc5b75e1cb99a711@HIDDEN>
Date: Wed, 20 Mar 2024 19:07:56 +0100
Message-ID: <8734skzshv.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: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi Richard and all,

Richard Sent <richard@HIDDEN> skribis:

> However, when fish is in charge of executing on-first-login, stdout and=20
> stderr for the user shepherd get directed to a pipe instead of=20
> /dev/null.
>
> fish fds, both stdout and stderr point to a pipe:
>
> $ ls -l /proc/<HERD_PID>/fd)
> lr-x------   1 richard        users    64 2023-11-16 14:47 0 ->=20
> /dev/null
> l-wx------   1 richard        users    64 2023-11-16 14:47 1 ->=20
> pipe:[41039]
> l-wx------   1 richard        users    64 2023-11-16 14:47 2 ->=20
> pipe:[41039]
> l-wx------   1 richard        users    64 2023-11-16 14:47 6 ->=20
> /home/richard/.local/state/log/shepherd.log
> // ...
>
>
> fish login shell strace of herd:
>
> 21:46:43 write(1, "Spawning systemd-style service=20
> /gnu/store/2zgdxhbnkz8fgsb1l4xydm3nbvj66mih-gnupg-2.2.39/bin/gpg-agent.\n=
",=20
> 103) =3D -1 EPIPE (Broken pipe)

(I assume this is the strace of shepherd, not herd.)

Maybe we should unconditionally run shepherd with stdout/stderr
redirected to /dev/null?

That would sidestep the problem and it=E2=80=99s probably a good idea anywa=
y.

WDYT?

Ludo=E2=80=99.

Last modified: Wed, 20 Mar 2024 18:15:02 UTC

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