From unknown Tue Aug 19 23:15:24 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork Resent-From: Jelle Licht Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 02 Jul 2017 01:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 27553 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 27553@debbugs.gnu.org X-Debbugs-Original-To: guix-patches@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14989578772823 (code B ref -1); Sun, 02 Jul 2017 01:12:01 +0000 Received: (at submit) by debbugs.gnu.org; 2 Jul 2017 01:11:17 +0000 Received: from localhost ([127.0.0.1]:48060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRTPx-0000jT-9n for submit@debbugs.gnu.org; Sat, 01 Jul 2017 21:11:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37277) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRTPw-0000jH-Ev for submit@debbugs.gnu.org; Sat, 01 Jul 2017 21:11:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRTPp-00071S-Tr for submit@debbugs.gnu.org; Sat, 01 Jul 2017 21:11:11 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:32768) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dRTPp-00071M-QM for submit@debbugs.gnu.org; Sat, 01 Jul 2017 21:11:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRTPo-000775-JG for guix-patches@gnu.org; Sat, 01 Jul 2017 21:11:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRTPn-000709-C2 for guix-patches@gnu.org; Sat, 01 Jul 2017 21:11:08 -0400 Received: from mail.fsfe.org ([2001:aa8:ffed::3:102]:33212) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dRTPn-0006zP-1k for guix-patches@gnu.org; Sat, 01 Jul 2017 21:11:07 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.fsfe.org (Postfix) with ESMTP id F20A46392C5 for ; Sun, 2 Jul 2017 03:11:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.fsfe.org Received: from mail.fsfe.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J2T+oZ2u9pk for ; Sun, 2 Jul 2017 03:11:04 +0200 (CEST) Received: by mail-it0-f50.google.com with SMTP id m84so41541116ita.0 for ; Sat, 01 Jul 2017 18:11:04 -0700 (PDT) X-Gm-Message-State: AKS2vOzN7mZHhnZmvYxn1eCTP0X4buHjenFk3r5LgdRA1niX4PLGWqMF b0QGSWAo8fN3VlyRxvpd74A5kX8Dpg== X-Received: by 10.36.41.138 with SMTP id p132mr26802999itp.49.1498957862079; Sat, 01 Jul 2017 18:11:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.172.66 with HTTP; Sat, 1 Jul 2017 18:11:01 -0700 (PDT) From: Jelle Licht Date: Sun, 2 Jul 2017 03:11:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Content-Type: multipart/mixed; boundary="001a113f6a54e744a005534b5230" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -7.8 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.8 (-------) --001a113f6a54e744a005534b5230 Content-Type: multipart/alternative; boundary="001a113f6a54e7449c05534b522e" --001a113f6a54e7449c05534b522e Content-Type: text/plain; charset="UTF-8" Hi all, I am not sure if this is also the proper ML for the GNU Shepherd, but looking in the archives lead me to believe it actually is. If not, I suggest the gnu.org page for shepherd be updated with the correct info. I recently starting playing around with user shepherd, and found out that when running a shepherd 0.3.2 daemonized as non-init process (via "(action 'shepherd 'daemonize)"), zombie processes are created whenever you start and subsequently stop any service. Thinking I did something wrong, I asked lfam on #guix to share his (very helpful) init.scm for user shepherd, yet I still noticed the same behaviour. I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828db' inadvertently introduced an ordering issue, where the SIGCHLD handler is registered /before/ shepherd has the chance to daemonize. I believe the following trivial patch addresses this snafu. Regards, Jelle --001a113f6a54e7449c05534b522e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I am not sure if this = is also the proper ML for the GNU Shepherd, but looking in the archives lea= d me to believe it actually is. If not, I suggest the gnu.org page for shepherd be updated with the correct info.

I recently starting playing around with user shepherd, a= nd found out that when running a shepherd 0.3.2 daemonized as non-init proc= ess (via "(action 'shepherd 'daemonize)"), zombie process= es are created whenever you start and subsequently stop any service.
Thinking I did something wrong, I asked lfam on #guix to share= his (very helpful) init.scm for user shepherd, yet I still noticed the sam= e behaviour.

I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f82= 8db' inadvertently introduced an ordering issue, where the SIGCHLD hand= ler is registered /before/ shepherd has the chance to daemonize. I believe = the following trivial patch addresses this snafu.

Regards= ,
Jelle


--001a113f6a54e7449c05534b522e-- --001a113f6a54e744a005534b5230 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Register-SIGCHLD-handler-after-primitive-fork.patch" Content-Disposition: attachment; filename="0001-Register-SIGCHLD-handler-after-primitive-fork.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j4m0shec0 RnJvbSAyNjAzYTFmNDIwMTY2OGMxM2Y5OTJkYmRlM2RkNDZiZTRkYzJjMzFkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKZWxsZSBMaWNodCA8amxpY2h0QGZzZmUub3JnPgpEYXRlOiBT dW4sIDIgSnVsIDIwMTcgMDI6NTg6MzYgKzAyMDAKU3ViamVjdDogW1BBVENIXSBSZWdpc3RlciBT SUdDSExEIGhhbmRsZXIgYWZ0ZXIgcHJpbWl0aXZlLWZvcmsuCgoqIG1vZHVsZXMvc2hlcGhlcmQu c2NtIChtYWluKTogTW92ZSBjYWxsIHRvICdzaWdhY3Rpb24nIHNvIGRhZW1vbml6ZWQgcHJvY2Vz cwogIGNhbiBoYW5kbGUgU0lHQ0hMRCBzaWduYWwuCi0tLQogbW9kdWxlcy9zaGVwaGVyZC5zY20g fCA2ICsrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMo LSkKCmRpZmYgLS1naXQgYS9tb2R1bGVzL3NoZXBoZXJkLnNjbSBiL21vZHVsZXMvc2hlcGhlcmQu c2NtCmluZGV4IGY3YzE2OWQuLmRmYWU3ZDYgMTAwNjQ0Ci0tLSBhL21vZHVsZXMvc2hlcGhlcmQu c2NtCisrKyBiL21vZHVsZXMvc2hlcGhlcmQuc2NtCkBAIC0xNDIsOSArMTQyLDYgQEAKICAgICA7 OyBTdGFydCB0aGUgJ3Jvb3QnIHNlcnZpY2UuCiAgICAgKHN0YXJ0IHJvb3Qtc2VydmljZSkKIAot ICAgIDs7IEluc3RhbGwgdGhlIFNJR0NITEQgaGFuZGxlci4KLSAgICAoc2lnYWN0aW9uIFNJR0NI TEQgcmVzcGF3bi1zZXJ2aWNlIFNBX05PQ0xEU1RPUCkKLQogICAgIDs7IFRoaXMgX211c3RfIHN1 Y2NlZWQuICAoV2UgY291bGQgYWxzbyBwdXQgdGhlIGBjYXRjaCcgYXJvdW5kCiAgICAgOzsgYG1h aW4nLCBidXQgaXQgaXMgb2Z0ZW4gdXNlZnVsIHRvIGdldCB0aGUgYmFja3RyYWNlLCBhbmQKICAg ICA7OyBgY2F1Z2h0LWVycm9yJyBkb2VzIG5vdCBkbyB0aGlzIHlldC4pCkBAIC0xNjQsNiArMTYx LDkgQEAKIAkgICAgIChhcHBseSBmb3JtYXQgI2YgKGdldHRleHQgKGNhZHIgYXJncykpIChjYWRk ciBhcmdzKSkKIAkgICAgIChxdWl0IDEpKSkpCiAKKyAgICA7OyBJbnN0YWxsIHRoZSBTSUdDSExE IGhhbmRsZXIuCisgICAgKHNpZ2FjdGlvbiBTSUdDSExEIHJlc3Bhd24tc2VydmljZSBTQV9OT0NM RFNUT1ApCisKICAgICAod2hlbiAocHJvdmlkZWQ/ICd0aHJlYWRzKQogICAgICAgOzsgWFhYOiBU aGlzIHRlcnJpYmxlIGhhY2sgYWxsb3dzIHVzIHRvIG1ha2Ugc3VyZSB0aGF0IHNpZ25hbCBoYW5k bGVycwogICAgICAgOzsgZ2V0IGEgY2hhbmNlIHRvIHJ1biBpbiBhIHRpbWVseSBmYXNoaW9uLiAg V2l0aG91dCBpdCwgYWZ0ZXIgYW4gRUlOVFIsCi0tIAoyLjEzLjIKCg== --001a113f6a54e744a005534b5230-- From unknown Tue Aug 19 23:15:24 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 12 Jul 2017 21:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27553 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Jelle Licht Cc: 27553@debbugs.gnu.org Received: via spool by 27553-submit@debbugs.gnu.org id=B27553.149989526528947 (code B ref 27553); Wed, 12 Jul 2017 21:35:01 +0000 Received: (at 27553) by debbugs.gnu.org; 12 Jul 2017 21:34:25 +0000 Received: from localhost ([127.0.0.1]:35895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVPH6-0007Wo-LF for submit@debbugs.gnu.org; Wed, 12 Jul 2017 17:34:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40699) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVPH3-0007Wa-O9 for 27553@debbugs.gnu.org; Wed, 12 Jul 2017 17:34:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVPGv-0002rk-9q for 27553@debbugs.gnu.org; Wed, 12 Jul 2017 17:34:16 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVPGv-0002re-5l; Wed, 12 Jul 2017 17:34:13 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:36222 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dVPGu-0006Ia-JC; Wed, 12 Jul 2017 17:34:12 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 24 Messidor an 225 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Wed, 12 Jul 2017 23:34:10 +0200 In-Reply-To: (Jelle Licht's message of "Sun, 2 Jul 2017 03:11:01 +0200") Message-ID: <87a849bar1.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hi Jelle, Jelle Licht skribis: > I am not sure if this is also the proper ML for the GNU Shepherd, but > looking in the archives lead me to believe it actually is. If not, I > suggest the gnu.org page for shepherd be updated with the correct info. It=E2=80=99s the right list. :-) > I recently starting playing around with user shepherd, and found out that > when running a shepherd 0.3.2 daemonized as non-init process (via "(action > 'shepherd 'daemonize)"), zombie processes are created whenever you start > and subsequently stop any service. > > Thinking I did something wrong, I asked lfam on #guix to share his (very > helpful) init.scm for user shepherd, yet I still noticed the same behavio= ur. > > I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828db' inadvertently > introduced an ordering issue, where the SIGCHLD handler is registered > /before/ shepherd has the chance to daemonize. I believe the following > trivial patch addresses this snafu. The config file can start services, so the SIGCHLD handler must be installed before we read the config file (otherwise we could be missing some process termination notifications.) Perhaps a solution would be to install the SIGCHLD handler lazily upon the first =E2=80=98fork+exec-command=E2=80=99 call? That would ensure both= that (1) users have a chance to daemonize before the handler is installed, and (2) that the handler is installed before services are started. Thoughts? Ludo=E2=80=99. From unknown Tue Aug 19 23:15:24 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork Resent-From: Jelle Licht Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 14 Jul 2017 12:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27553 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 27553@debbugs.gnu.org Received: via spool by 27553-submit@debbugs.gnu.org id=B27553.150003476827096 (code B ref 27553); Fri, 14 Jul 2017 12:20:02 +0000 Received: (at 27553) by debbugs.gnu.org; 14 Jul 2017 12:19:28 +0000 Received: from localhost ([127.0.0.1]:37838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVzZ8-00072u-Pv for submit@debbugs.gnu.org; Fri, 14 Jul 2017 08:19:28 -0400 Received: from mail.fsfe.org ([217.69.89.162]:51217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVzZ6-00072f-CC for 27553@debbugs.gnu.org; Fri, 14 Jul 2017 08:19:25 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.fsfe.org (Postfix) with ESMTP id 2D213639958 for <27553@debbugs.gnu.org>; Fri, 14 Jul 2017 14:19:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.fsfe.org Received: from mail.fsfe.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpSlG4RO59WJ for <27553@debbugs.gnu.org>; Fri, 14 Jul 2017 14:19:17 +0200 (CEST) Received: by mail-it0-f53.google.com with SMTP id v202so19347857itb.0 for <27553@debbugs.gnu.org>; Fri, 14 Jul 2017 05:19:15 -0700 (PDT) X-Gm-Message-State: AIVw1110N/LJjfFqP2yoS3soCBMBfSxwW6SknD9/ozLlPFdIHOqeULN9 0LknS8jNAXOBOJJUyQ6GYClOOqLyEQ== X-Received: by 10.36.172.29 with SMTP id s29mr3442302ite.32.1500034753530; Fri, 14 Jul 2017 05:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.175.7 with HTTP; Fri, 14 Jul 2017 05:19:12 -0700 (PDT) In-Reply-To: <87a849bar1.fsf@gnu.org> References: <87a849bar1.fsf@gnu.org> From: Jelle Licht Date: Fri, 14 Jul 2017 14:19:12 +0200 X-Gmail-Original-Message-ID: Message-ID: Content-Type: multipart/alternative; boundary="94eb2c1f9ec0a2bc360554460e0e" X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) --94eb2c1f9ec0a2bc360554460e0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ludo, 2017-07-12 23:34 GMT+02:00 Ludovic Court=C3=A8s : > Hi Jelle, > > Jelle Licht skribis: > > > I am not sure if this is also the proper ML for the GNU Shepherd, but > > looking in the archives lead me to believe it actually is. If not, I > > suggest the gnu.org page for shepherd be updated with the correct info. > > It=E2=80=99s the right list. :-) > I am glad it turned out to be :-). Perhaps [1] can be updated to the same info as [2]? > > > I recently starting playing around with user shepherd, and found out th= at > > when running a shepherd 0.3.2 daemonized as non-init process (via > "(action > > 'shepherd 'daemonize)"), zombie processes are created whenever you star= t > > and subsequently stop any service. > > > > Thinking I did something wrong, I asked lfam on #guix to share his (ver= y > > helpful) init.scm for user shepherd, yet I still noticed the same > behaviour. > > > > I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828db' > inadvertently > > introduced an ordering issue, where the SIGCHLD handler is registered > > /before/ shepherd has the chance to daemonize. I believe the following > > trivial patch addresses this snafu. > > The config file can start services, so the SIGCHLD handler must be > installed before we read the config file (otherwise we could be missing > some process termination notifications.) > What do you mean exactly? I think my config file does this, and I have not yet noticed this issue, but I might just be confused about what you mean here. > > Perhaps a solution would be to install the SIGCHLD handler lazily upon > the first =E2=80=98fork+exec-command=E2=80=99 call? That would ensure bo= th that (1) > users have a chance to daemonize before the handler is installed, and > (2) that the handler is installed before services are started. > > Thoughts? > This seems like it would be for the best. I actually have no clue how to implement this though. Regards, Jelle [1]: https://www.gnu.org/software/shepherd/ [2]: https://www.gnu.org/software/guix/about/#contact --94eb2c1f9ec0a2bc360554460e0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ludo,

2017-07-12 23:34 GMT+02:00 Ludovic Court=C3=A8s <ludo@gnu.org= >:
Hi Je= lle,

Jelle Licht <jlicht= @fsfe.org> skribis:

> I am not sure if this is also the proper ML for the GNU Shepherd, but<= br> > looking in the archives lead me to believe it actually is. If not, I > suggest the gnu.org page for shepherd be updated with the correct info.

It=E2=80=99s the right list.=C2=A0 :-)
I am gla= d it turned out to be :-). Perhaps [1] can be updated to the same info as [= 2]?
=C2=A0

> I recently starting playing around with user shepherd, and found out t= hat
> when running a shepherd 0.3.2 daemonized as non-init process (via &quo= t;(action
> 'shepherd 'daemonize)"), zombie processes are created whe= never you start
> and subsequently stop any service.
>
> Thinking I did something wrong, I asked lfam on #guix to share his (ve= ry
> helpful) init.scm for user shepherd, yet I still noticed the same beha= viour.
>
> I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828db' i= nadvertently
> introduced an ordering issue, where the SIGCHLD handler is registered<= br> > /before/ shepherd has the chance to daemonize. I believe the following=
> trivial patch addresses this snafu.

The config file can start services, so the SIGCHLD handler must be installed before we read the config file (otherwise we could be missing
some process termination notifications.)
What do you = mean exactly? I think my config file does this, and I have not yet noticed = this issue,
but I might just be confused about what you mean = here.
=C2=A0

Perhaps a solution would be to install the SIGCHLD handler lazily upon
the first =E2=80=98fork+exec-command=E2=80=99 call?=C2=A0 That would ensure= both that (1)
users have a chance to daemonize before the handler is installed, and
(2) that the handler is installed before services are started.

Thoughts?
This seems like it would be for the best. I = actually have no clue how to implement this though.
=C2=A0
Regards,
--94eb2c1f9ec0a2bc360554460e0e-- From unknown Tue Aug 19 23:15:24 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 17 Jul 2017 08:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27553 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Jelle Licht Cc: 27553@debbugs.gnu.org Received: via spool by 27553-submit@debbugs.gnu.org id=B27553.150028039815074 (code B ref 27553); Mon, 17 Jul 2017 08:34:01 +0000 Received: (at 27553) by debbugs.gnu.org; 17 Jul 2017 08:33:18 +0000 Received: from localhost ([127.0.0.1]:43181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dX1Sw-0003v4-FE for submit@debbugs.gnu.org; Mon, 17 Jul 2017 04:33:18 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dX1Su-0003up-5J for 27553@debbugs.gnu.org; Mon, 17 Jul 2017 04:33:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dX1Sk-00061X-4m for 27553@debbugs.gnu.org; Mon, 17 Jul 2017 04:33:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dX1Sk-00061T-1v; Mon, 17 Jul 2017 04:33:06 -0400 Received: from [193.50.110.212] (port=51246 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dX1Sj-0004h4-Ja; Mon, 17 Jul 2017 04:33:05 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87a849bar1.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 29 Messidor an 225 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Mon, 17 Jul 2017 10:33:03 +0200 In-Reply-To: (Jelle Licht's message of "Fri, 14 Jul 2017 14:19:12 +0200") Message-ID: <87wp77ea4g.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hi Jelle, Jelle Licht skribis: > 2017-07-12 23:34 GMT+02:00 Ludovic Court=C3=A8s : > >> Hi Jelle, >> >> Jelle Licht skribis: >> >> > I am not sure if this is also the proper ML for the GNU Shepherd, but >> > looking in the archives lead me to believe it actually is. If not, I >> > suggest the gnu.org page for shepherd be updated with the correct info. >> >> It=E2=80=99s the right list. :-) >> > I am glad it turned out to be :-). Perhaps [1] can be updated to the same > info as [2]? Done! >> > I recently starting playing around with user shepherd, and found out t= hat >> > when running a shepherd 0.3.2 daemonized as non-init process (via >> "(action >> > 'shepherd 'daemonize)"), zombie processes are created whenever you sta= rt >> > and subsequently stop any service. >> > >> > Thinking I did something wrong, I asked lfam on #guix to share his (ve= ry >> > helpful) init.scm for user shepherd, yet I still noticed the same >> behaviour. >> > >> > I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828db' >> inadvertently >> > introduced an ordering issue, where the SIGCHLD handler is registered >> > /before/ shepherd has the chance to daemonize. I believe the following >> > trivial patch addresses this snafu. >> >> The config file can start services, so the SIGCHLD handler must be >> installed before we read the config file (otherwise we could be missing >> some process termination notifications.) >> > What do you mean exactly? I think my config file does this, and I have not > yet noticed this issue, > but I might just be confused about what you mean here. If the config file spawns a process and that process dies before we have installed the SIGCHLD handler, then we=E2=80=99ll never know that it has terminated. >> Perhaps a solution would be to install the SIGCHLD handler lazily upon >> the first =E2=80=98fork+exec-command=E2=80=99 call? That would ensure b= oth that (1) >> users have a chance to daemonize before the handler is installed, and >> (2) that the handler is installed before services are started. >> >> Thoughts? >> > This seems like it would be for the best. I actually have no clue how to > implement this though. I=E2=80=99d imagine something like a global variable (a Boolean) telling wh= ether the SIGCHLD handler is installed, and then: (unless %sigchld-handler-installed? (sigaction =E2=80=A6) (set! %sigchld-handler-installed? #t)) Thoughts? Ludo=E2=80=99. From unknown Tue Aug 19 23:15:24 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork Resent-From: Jelle Licht Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 27 Jul 2017 14:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27553 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 27553@debbugs.gnu.org Received: via spool by 27553-submit@debbugs.gnu.org id=B27553.150116593917262 (code B ref 27553); Thu, 27 Jul 2017 14:33:01 +0000 Received: (at 27553) by debbugs.gnu.org; 27 Jul 2017 14:32:19 +0000 Received: from localhost ([127.0.0.1]:58759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dajpq-0004UL-Nb for submit@debbugs.gnu.org; Thu, 27 Jul 2017 10:32:19 -0400 Received: from mail.fsfe.org ([217.69.89.162]:54083) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dajpo-0004U7-Or for 27553@debbugs.gnu.org; Thu, 27 Jul 2017 10:32:17 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.fsfe.org (Postfix) with ESMTP id ABEDF639CEF for <27553@debbugs.gnu.org>; Thu, 27 Jul 2017 16:32:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.fsfe.org Received: from mail.fsfe.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgPTXijijBs0 for <27553@debbugs.gnu.org>; Thu, 27 Jul 2017 16:32:10 +0200 (CEST) Received: by mail-it0-f49.google.com with SMTP id v205so66799797itf.1 for <27553@debbugs.gnu.org>; Thu, 27 Jul 2017 07:32:09 -0700 (PDT) X-Gm-Message-State: AIVw113cC0HSo9c7YXQlyQC2m5dYIR/WJCT50D0Zc6omO8hchlW6g/4D EY6ydVxz2iX6rxlAPvILur/edA8X1A== X-Received: by 10.36.9.6 with SMTP id 6mr5288491itm.152.1501165924339; Thu, 27 Jul 2017 07:32:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.175.81 with HTTP; Thu, 27 Jul 2017 07:32:03 -0700 (PDT) In-Reply-To: <87wp77ea4g.fsf@gnu.org> References: <87a849bar1.fsf@gnu.org> <87wp77ea4g.fsf@gnu.org> From: Jelle Licht Date: Thu, 27 Jul 2017 16:32:03 +0200 X-Gmail-Original-Message-ID: Message-ID: Content-Type: multipart/alternative; boundary="001a1143ea62ab712405554d6d14" X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) --001a1143ea62ab712405554d6d14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ludo, The documentation for the `daemonize' action specifies the following: > "Go into the background. Be careful, this means that a new > process will be created, so shepherd will not get SIGCHLD signals anymore > if previously spawned childs terminate. Therefore, this action should > usually only be used (if at all) *before* childs get spawned for which > we want to receive these signals." > > In a sense, the problem that you describe can then be solved by having the lazy SIGCHLD handler be registered in two places: - Immediately after a call to the `daemonize' action, as its documentation that if called, it should be done before starting any services - Before calling the lambda stored in the `start' slot of any non-root-service service I know how to do the first one (the newly forked process should lazily register the handler), but the second one seems a bit harder to do. I could add a special case to the `start' method so that it will lazily install the handler unless we are starting the root-service, but that seems inelegant somehow. 2017-07-17 10:33 GMT+02:00 Ludovic Court=C3=A8s : > Hi Jelle, > > Jelle Licht skribis: > > > 2017-07-12 23:34 GMT+02:00 Ludovic Court=C3=A8s : > > > >> Hi Jelle, > >> > >> Jelle Licht skribis: > >> > >> > I am not sure if this is also the proper ML for the GNU Shepherd, bu= t > >> > looking in the archives lead me to believe it actually is. If not, I > >> > suggest the gnu.org page for shepherd be updated with the correct > info. > >> > >> It=E2=80=99s the right list. :-) > >> > > I am glad it turned out to be :-). Perhaps [1] can be updated to the sa= me > > info as [2]? > > Done! > > >> > I recently starting playing around with user shepherd, and found out > that > >> > when running a shepherd 0.3.2 daemonized as non-init process (via > >> "(action > >> > 'shepherd 'daemonize)"), zombie processes are created whenever you > start > >> > and subsequently stop any service. > >> > > >> > Thinking I did something wrong, I asked lfam on #guix to share his > (very > >> > helpful) init.scm for user shepherd, yet I still noticed the same > >> behaviour. > >> > > >> > I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828db' > >> inadvertently > >> > introduced an ordering issue, where the SIGCHLD handler is registere= d > >> > /before/ shepherd has the chance to daemonize. I believe the followi= ng > >> > trivial patch addresses this snafu. > >> > >> The config file can start services, so the SIGCHLD handler must be > >> installed before we read the config file (otherwise we could be missin= g > >> some process termination notifications.) > >> > > What do you mean exactly? I think my config file does this, and I have > not > > yet noticed this issue, > > but I might just be confused about what you mean here. > > If the config file spawns a process and that process dies before we have > installed the SIGCHLD handler, then we=E2=80=99ll never know that it has > terminated. > > >> Perhaps a solution would be to install the SIGCHLD handler lazily upon > >> the first =E2=80=98fork+exec-command=E2=80=99 call? That would ensure= both that (1) > >> users have a chance to daemonize before the handler is installed, and > >> (2) that the handler is installed before services are started. > >> > >> Thoughts? > >> > > This seems like it would be for the best. I actually have no clue how t= o > > implement this though. > > I=E2=80=99d imagine something like a global variable (a Boolean) telling = whether > the SIGCHLD handler is installed, and then: > > (unless %sigchld-handler-installed? > (sigaction =E2=80=A6) > (set! %sigchld-handler-installed? #t)) > > Thoughts? > > Ludo=E2=80=99. > --001a1143ea62ab712405554d6d14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ludo,

The documentation for the `daem= onize' action specifies the following:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Go into the backg= round.=C2=A0 Be careful, this means that a new
process will be created, = so shepherd will not get SIGCHLD signals anymore
if previously spawned c= hilds terminate.=C2=A0 Therefore, this action should
usually only be use= d (if at all) *before* childs get spawned for which
we want to receive t= hese signals."


In a sense, the= problem that you describe can then be solved=C2=A0 by having the lazy SIGC= HLD handler be registered in two places:
- Immediately after = a call to the `daemonize' action, as its documentation that if called, = it should be done before starting any services
- Before calli= ng the lambda stored in the `start' slot of any non-root-service servic= e

I know how to do the first one (the newly forked proces= s should lazily register the handler), but the second one seems a bit harde= r to do.
I could add a special case to the `start' method= so that it will lazily install the handler unless we are starting the root= -service, but that seems
inelegant somehow.


2017-07-17 10:= 33 GMT+02:00 Ludovic Court=C3=A8s <ludo@gnu.org>:
Hi Jelle,

Jelle Licht <jlicht@fsfe.org> = skribis:

> 2017-07-12 23:34 GMT+02:00 Ludovic Court=C3=A8s <ludo@gnu.org>:
>
>> Hi Jelle,
>>
>> Jelle Licht <jlicht@fsfe.org= > skribis:
>>
>> > I am not sure if this is also the proper ML for the GNU Sheph= erd, but
>> > looking in the archives lead me to believe it actually is. If= not, I
>> > suggest the gnu.org page for shepherd be updated with the correct in= fo.
>>
>> It=E2=80=99s the right list.=C2=A0 :-)
>>
> I am glad it turned out to be :-). Perhaps [1] can be updated to the s= ame
> info as [2]?

Done!

>> > I recently starting playing around with user shepherd, and fo= und out that
>> > when running a shepherd 0.3.2 daemonized as non-init process = (via
>> "(action
>> > 'shepherd 'daemonize)"), zombie processes are cr= eated whenever you start
>> > and subsequently stop any service.
>> >
>> > Thinking I did something wrong, I asked lfam on #guix to shar= e his (very
>> > helpful) init.scm for user shepherd, yet I still noticed the = same
>> behaviour.
>> >
>> > I believe commit `efa2f45c5f7dc735407381b7b8a83d6c3= 7f828db'
>> inadvertently
>> > introduced an ordering issue, where the SIGCHLD handler is re= gistered
>> > /before/ shepherd has the chance to daemonize. I believe the = following
>> > trivial patch addresses this snafu.
>>
>> The config file can start services, so the SIGCHLD handler must be=
>> installed before we read the config file (otherwise we could be mi= ssing
>> some process termination notifications.)
>>
> What do you mean exactly? I think my config file does this, and I have= not
> yet noticed this issue,
> but I might just be confused about what you mean here.

If the config file spawns a process and that process dies before we = have
installed the SIGCHLD handler, then we=E2=80=99ll never know that it has terminated.

>> Perhaps a solution would be to install the SIGCHLD handler lazily = upon
>> the first =E2=80=98fork+exec-command=E2=80=99 call?=C2=A0 That wou= ld ensure both that (1)
>> users have a chance to daemonize before the handler is installed, = and
>> (2) that the handler is installed before services are started.
>>
>> Thoughts?
>>
> This seems like it would be for the best. I actually have no clue how = to
> implement this though.

I=E2=80=99d imagine something like a global variable (a Boolean) tel= ling whether
the SIGCHLD handler is installed, and then:

=C2=A0 (unless %sigchld-handler-installed?
=C2=A0 =C2=A0 (sigaction =E2=80=A6)
=C2=A0 =C2=A0 (set! %sigchld-handler-installed? #t))

Thoughts?

Ludo=E2=80=99.

--001a1143ea62ab712405554d6d14-- From unknown Tue Aug 19 23:15:24 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork Resent-From: Jelle Licht Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 06 Sep 2017 22:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27553 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 27553@debbugs.gnu.org Received: via spool by 27553-submit@debbugs.gnu.org id=B27553.150473861425860 (code B ref 27553); Wed, 06 Sep 2017 22:57:01 +0000 Received: (at 27553) by debbugs.gnu.org; 6 Sep 2017 22:56:54 +0000 Received: from localhost ([127.0.0.1]:53588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpjFd-0006j1-VC for submit@debbugs.gnu.org; Wed, 06 Sep 2017 18:56:54 -0400 Received: from mail.fsfe.org ([217.69.89.162]:59727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpjFb-0006ij-KM for 27553@debbugs.gnu.org; Wed, 06 Sep 2017 18:56:52 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.fsfe.org (Postfix) with ESMTP id 59066639293 for <27553@debbugs.gnu.org>; Thu, 7 Sep 2017 00:56:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.fsfe.org Received: from mail.fsfe.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaA1-XEyzCDS for <27553@debbugs.gnu.org>; Thu, 7 Sep 2017 00:56:45 +0200 (CEST) Received: by mail-vk0-f54.google.com with SMTP id v203so13281718vkv.3 for <27553@debbugs.gnu.org>; Wed, 06 Sep 2017 15:56:44 -0700 (PDT) X-Gm-Message-State: AHPjjUjfGFYyh9f2ZZIGV8lFIc96+ZlgO0KMaJwAxDcR3buGmONvrxUy oi6WJGaBvPa8ae9/043GqFlk9gWUNg== X-Google-Smtp-Source: ADKCNb7XttegSQcT5K6lk0QKkz2pZt4JbGg3F23SWiKMvCtxukQTjOlyR6JOEkn4jk1thTs3NAVknp1dHEXrIZbhzVc= X-Received: by 10.31.61.136 with SMTP id k130mr428051vka.45.1504738602415; Wed, 06 Sep 2017 15:56:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.122.81 with HTTP; Wed, 6 Sep 2017 15:56:41 -0700 (PDT) In-Reply-To: References: <87a849bar1.fsf@gnu.org> <87wp77ea4g.fsf@gnu.org> From: Jelle Licht Date: Thu, 7 Sep 2017 00:56:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Content-Type: multipart/mixed; boundary="001a114dba3ee0e75405588d416f" X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) --001a114dba3ee0e75405588d416f Content-Type: multipart/alternative; boundary="001a114dba3ee0e74f05588d416d" --001a114dba3ee0e74f05588d416d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I just tested what Ludo' proposed, and it seems to work like a charm. Seeing as we might be seeing more non-init shepherd instances w.r.t. user services and the possible service extension to `guix environment', I think it would be a good call to fix this bug :-). Regards, Jelle 2017-07-27 16:32 GMT+02:00 Jelle Licht : > Hi Ludo, > > The documentation for the `daemonize' action specifies the following: > >> "Go into the background. Be careful, this means that a new >> process will be created, so shepherd will not get SIGCHLD signals anymor= e >> if previously spawned childs terminate. Therefore, this action should >> usually only be used (if at all) *before* childs get spawned for which >> we want to receive these signals." >> >> > In a sense, the problem that you describe can then be solved by having > the lazy SIGCHLD handler be registered in two places: > - Immediately after a call to the `daemonize' action, as its documentatio= n > that if called, it should be done before starting any services > - Before calling the lambda stored in the `start' slot of any > non-root-service service > > I know how to do the first one (the newly forked process should lazily > register the handler), but the second one seems a bit harder to do. > I could add a special case to the `start' method so that it will lazily > install the handler unless we are starting the root-service, but that see= ms > inelegant somehow. > > > 2017-07-17 10:33 GMT+02:00 Ludovic Court=C3=A8s : > >> Hi Jelle, >> >> Jelle Licht skribis: >> >> > 2017-07-12 23:34 GMT+02:00 Ludovic Court=C3=A8s : >> > >> >> Hi Jelle, >> >> >> >> Jelle Licht skribis: >> >> >> >> > I am not sure if this is also the proper ML for the GNU Shepherd, b= ut >> >> > looking in the archives lead me to believe it actually is. If not, = I >> >> > suggest the gnu.org page for shepherd be updated with the correct >> info. >> >> >> >> It=E2=80=99s the right list. :-) >> >> >> > I am glad it turned out to be :-). Perhaps [1] can be updated to the >> same >> > info as [2]? >> >> Done! >> >> >> > I recently starting playing around with user shepherd, and found ou= t >> that >> >> > when running a shepherd 0.3.2 daemonized as non-init process (via >> >> "(action >> >> > 'shepherd 'daemonize)"), zombie processes are created whenever you >> start >> >> > and subsequently stop any service. >> >> > >> >> > Thinking I did something wrong, I asked lfam on #guix to share his >> (very >> >> > helpful) init.scm for user shepherd, yet I still noticed the same >> >> behaviour. >> >> > >> >> > I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828db' >> >> inadvertently >> >> > introduced an ordering issue, where the SIGCHLD handler is register= ed >> >> > /before/ shepherd has the chance to daemonize. I believe the >> following >> >> > trivial patch addresses this snafu. >> >> >> >> The config file can start services, so the SIGCHLD handler must be >> >> installed before we read the config file (otherwise we could be missi= ng >> >> some process termination notifications.) >> >> >> > What do you mean exactly? I think my config file does this, and I have >> not >> > yet noticed this issue, >> > but I might just be confused about what you mean here. >> >> If the config file spawns a process and that process dies before we have >> installed the SIGCHLD handler, then we=E2=80=99ll never know that it has >> terminated. >> >> >> Perhaps a solution would be to install the SIGCHLD handler lazily upo= n >> >> the first =E2=80=98fork+exec-command=E2=80=99 call? That would ensur= e both that (1) >> >> users have a chance to daemonize before the handler is installed, and >> >> (2) that the handler is installed before services are started. >> >> >> >> Thoughts? >> >> >> > This seems like it would be for the best. I actually have no clue how = to >> > implement this though. >> >> I=E2=80=99d imagine something like a global variable (a Boolean) telling= whether >> the SIGCHLD handler is installed, and then: >> >> (unless %sigchld-handler-installed? >> (sigaction =E2=80=A6) >> (set! %sigchld-handler-installed? #t)) >> >> Thoughts? >> >> Ludo=E2=80=99. >> > > --001a114dba3ee0e74f05588d416d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just tested what Ludo' proposed, and it seems to wor= k like a charm.
Seeing as we might be seeing more non-init shepherd ins= tances w.r.t.
=C2=A0user services and the possible service extens= ion to `guix environment',
I think it would be a good call to= fix this bug :-).

Regards,
Jelle



2017-07-27 16:32 GMT+02:00 Jelle Licht <jlicht@fsfe.or= g>:
H= i Ludo,

The documentation for the `daemonize' action speci= fies the following:
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Go into the background.=C2=A0 Be caref= ul, this means that a new
process will be created, so shepherd will not = get SIGCHLD signals anymore
if previously spawned childs terminate.=C2= =A0 Therefore, this action should
usually only be used (if at all) *befo= re* childs get spawned for which
we want to receive these signals."=


In a sense, the problem that you d= escribe can then be solved=C2=A0 by having the lazy SIGCHLD handler be regi= stered in two places:
- Immediately after a call to the `daem= onize' action, as its documentation that if called, it should be done b= efore starting any services
- Before calling the lambda store= d in the `start' slot of any non-root-service service

I know how to do the first one (the newly forked process should lazily reg= ister the handler), but the second one seems a bit harder to do.
<= div>I could add a special case to the `start' method so that it will la= zily install the handler unless we are starting the root-service, but that = seems
inelegant somehow.


2017-07-17 10:33 GMT+02:00 Ludovic Court=C3=A8s &l= t;ludo@gnu.org>:
Hi Jelle,

Jelle Licht <jlicht= @fsfe.org> skribis:

> 2017-07-12 23:34 GMT+02:00 Ludovic Court=C3=A8s <ludo@gnu.org>:
>
>> Hi Jelle,
>>
>> Jelle Licht <jlicht@fsfe.org> skribis:
>>
>> > I am not sure if this is also the proper ML for the GNU Sheph= erd, but
>> > looking in the archives lead me to believe it actually is. If= not, I
>> > suggest the gnu.org page for shepherd be updated with the correct in= fo.
>>
>> It=E2=80=99s the right list.=C2=A0 :-)
>>
> I am glad it turned out to be :-). Perhaps [1] can be updated to the s= ame
> info as [2]?

Done!

>> > I recently starting playing around with user shepherd, and fo= und out that
>> > when running a shepherd 0.3.2 daemonized as non-init process = (via
>> "(action
>> > 'shepherd 'daemonize)"), zombie processes are cr= eated whenever you start
>> > and subsequently stop any service.
>> >
>> > Thinking I did something wrong, I asked lfam on #guix to shar= e his (very
>> > helpful) init.scm for user shepherd, yet I still noticed the = same
>> behaviour.
>> >
>> > I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828= db'
>> inadvertently
>> > introduced an ordering issue, where the SIGCHLD handler is re= gistered
>> > /before/ shepherd has the chance to daemonize. I believe the = following
>> > trivial patch addresses this snafu.
>>
>> The config file can start services, so the SIGCHLD handler must be=
>> installed before we read the config file (otherwise we could be mi= ssing
>> some process termination notifications.)
>>
> What do you mean exactly? I think my config file does this, and I have= not
> yet noticed this issue,
> but I might just be confused about what you mean here.

If the config file spawns a process and that process dies before we = have
installed the SIGCHLD handler, then we=E2=80=99ll never know that it has terminated.

>> Perhaps a solution would be to install the SIGCHLD handler lazily = upon
>> the first =E2=80=98fork+exec-command=E2=80=99 call?=C2=A0 That wou= ld ensure both that (1)
>> users have a chance to daemonize before the handler is installed, = and
>> (2) that the handler is installed before services are started.
>>
>> Thoughts?
>>
> This seems like it would be for the best. I actually have no clue how = to
> implement this though.

I=E2=80=99d imagine something like a global variable (a Boolean) tel= ling whether
the SIGCHLD handler is installed, and then:

=C2=A0 (unless %sigchld-handler-installed?
=C2=A0 =C2=A0 (sigaction =E2=80=A6)
=C2=A0 =C2=A0 (set! %sigchld-handler-installed? #t))

Thoughts?

Ludo=E2=80=99.


--001a114dba3ee0e74f05588d416d-- --001a114dba3ee0e75405588d416f Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Lazily-register-SIGCHLD-hander-on-first-call-to-fork.patch" Content-Disposition: attachment; filename="0001-Lazily-register-SIGCHLD-hander-on-first-call-to-fork.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j79mfbz50 RnJvbSBkYjk0MjE4MjIyNGRmYzBhY2NhZDk0ODk3ZGQyMTIyYjEyOGVlZjA3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKZWxsZSBMaWNodCA8amxpY2h0QGZzZmUub3JnPgpEYXRlOiBU aHUsIDcgU2VwIDIwMTcgMDA6NTI6NDkgKzAyMDAKU3ViamVjdDogW1BBVENIXSBMYXppbHkgcmVn aXN0ZXIgU0lHQ0hMRCBoYW5kZXIgb24gZmlyc3QgY2FsbCB0bwogJ2ZvcmsrZXhlYy1jb21tYW5k Jy4KCiogbW9kdWxlcy9zaGVwaGVyZC5zY20gKG1haW4pOiBNb3ZlIHVuY29uZGl0aW9uYWwgdG9w LWxldmVsIGNhbGwgdG8gJ3NpZ2FjdGlvbicgdG8uLi4KKiBtb2R1bGVzL3NoZXBoZXJkL3NlcnZp Y2Uuc2NtIChmb3JrK2V4ZWMtY29tbWFuZCk6IGhlcmUuIFVzZSBuZXcgdmFyaWFibGUuCiglc2ln Y2hsZC1oYW5kbGVyLWluc3RhbGxlZD8pOiBOZXcgdmFyaWFibGUuCi0tLQogbW9kdWxlcy9zaGVw aGVyZC5zY20gICAgICAgICB8IDMgLS0tCiBtb2R1bGVzL3NoZXBoZXJkL3NlcnZpY2Uuc2NtIHwg NyArKysrKysrCiAyIGZpbGVzIGNoYW5nZWQsIDcgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMo LSkKCmRpZmYgLS1naXQgYS9tb2R1bGVzL3NoZXBoZXJkLnNjbSBiL21vZHVsZXMvc2hlcGhlcmQu c2NtCmluZGV4IGY3YzE2OWQuLjdlYTY0OTMgMTAwNjQ0Ci0tLSBhL21vZHVsZXMvc2hlcGhlcmQu c2NtCisrKyBiL21vZHVsZXMvc2hlcGhlcmQuc2NtCkBAIC0xNDIsOSArMTQyLDYgQEAKICAgICA7 OyBTdGFydCB0aGUgJ3Jvb3QnIHNlcnZpY2UuCiAgICAgKHN0YXJ0IHJvb3Qtc2VydmljZSkKIAot ICAgIDs7IEluc3RhbGwgdGhlIFNJR0NITEQgaGFuZGxlci4KLSAgICAoc2lnYWN0aW9uIFNJR0NI TEQgcmVzcGF3bi1zZXJ2aWNlIFNBX05PQ0xEU1RPUCkKLQogICAgIDs7IFRoaXMgX211c3RfIHN1 Y2NlZWQuICAoV2UgY291bGQgYWxzbyBwdXQgdGhlIGBjYXRjaCcgYXJvdW5kCiAgICAgOzsgYG1h aW4nLCBidXQgaXQgaXMgb2Z0ZW4gdXNlZnVsIHRvIGdldCB0aGUgYmFja3RyYWNlLCBhbmQKICAg ICA7OyBgY2F1Z2h0LWVycm9yJyBkb2VzIG5vdCBkbyB0aGlzIHlldC4pCmRpZmYgLS1naXQgYS9t b2R1bGVzL3NoZXBoZXJkL3NlcnZpY2Uuc2NtIGIvbW9kdWxlcy9zaGVwaGVyZC9zZXJ2aWNlLnNj bQppbmRleCA3MmZiYzNkLi5iMmQ4YmM1IDEwMDY0NAotLS0gYS9tb2R1bGVzL3NoZXBoZXJkL3Nl cnZpY2Uuc2NtCisrKyBiL21vZHVsZXMvc2hlcGhlcmQvc2VydmljZS5zY20KQEAgLTEwMCw2ICsx MDAsOSBAQAogCiAgICAgICAgICAgICBjb25kaXRpb24tPnNleHApKQogCis7OyBLZWVwIHRyYWNr IG9mIGxhenkgaW5pdGlhbGl6YXRpb24gb2YgU0lHQ0hMRCBoYW5kbGVyCisoZGVmaW5lICVzaWdj aGxkLWhhbmRsZXItaW5zdGFsbGVkPyAjZikKKwogOzsgVHlwZSBvZiBzZXJ2aWNlIGFjdGlvbnMu CiAoZGVmaW5lLXJlY29yZC10eXBlIDxhY3Rpb24+CiAgIChtYWtlLWFjdGlvbiBuYW1lIHByb2Mg ZG9jKQpAQCAtNzg3LDYgKzc5MCwxMCBAQCBmYWxzZS4iCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIChkZWZhdWx0LWVudmlyb25tZW50LXZhcmlhYmxlcykpKQogICAiU3Bhd24gYSBwcm9j ZXNzIHRoYXQgZXhlY3V0ZWQgQ09NTUFORCBhcyBwZXIgJ2V4ZWMtY29tbWFuZCcsIGFuZCByZXR1 cm4KIGl0cyBQSUQuIgorICA7OyBJbnN0YWxsIHRoZSBTSUdDSExEIGhhbmRsZXIgaWYgdGhpcyBp cyB0aGUgZmlyc3QgZm9yaytleGVjLWNvbW1hbmQgY2FsbAorICAodW5sZXNzICVzaWdjaGxkLWhh bmRsZXItaW5zdGFsbGVkPworICAgIChzaWdhY3Rpb24gU0lHQ0hMRCByZXNwYXduLXNlcnZpY2Ug U0FfTk9DTERTVE9QKQorICAgIChzZXQhICVzaWdjaGxkLWhhbmRsZXItaW5zdGFsbGVkPyAjdCkp CiAgIChsZXQgKChwaWQgKHByaW1pdGl2ZS1mb3JrKSkpCiAgICAgKGlmICh6ZXJvPyBwaWQpCiAg ICAgICAgIChleGVjLWNvbW1hbmQgY29tbWFuZAotLSAKMi4xNC4xCgo= --001a114dba3ee0e75405588d416f-- From unknown Tue Aug 19 23:15:24 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Jelle Licht Subject: bug#27553: closed (Re: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork) Message-ID: References: <87o9qmtvgf.fsf@gnu.org> X-Gnu-PR-Message: they-closed 27553 X-Gnu-PR-Package: guix-patches X-Gnu-PR-Keywords: patch Reply-To: 27553@debbugs.gnu.org Date: Thu, 07 Sep 2017 14:50:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1504795802-5196-1" This is a multi-part message in MIME format... ------------=_1504795802-5196-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #27553: [PATCH shepherd] Register SIGCHLD handler after primitive fork which was filed against the guix-patches package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 27553@debbugs.gnu.org. --=20 27553: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27553 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1504795802-5196-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 27553-done) by debbugs.gnu.org; 7 Sep 2017 14:49:52 +0000 Received: from localhost ([127.0.0.1]:54499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpy7s-0001LO-9D for submit@debbugs.gnu.org; Thu, 07 Sep 2017 10:49:52 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpy7p-0001LA-T4 for 27553-done@debbugs.gnu.org; Thu, 07 Sep 2017 10:49:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dpy7g-0007Lw-7H for 27553-done@debbugs.gnu.org; Thu, 07 Sep 2017 10:49:44 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpy7g-0007Lm-3k; Thu, 07 Sep 2017 10:49:40 -0400 Received: from [193.50.110.57] (port=60604 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dpy7f-0000hV-Ly; Thu, 07 Sep 2017 10:49:39 -0400 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Jelle Licht Subject: Re: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork References: <87a849bar1.fsf@gnu.org> <87wp77ea4g.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 21 Fructidor an 225 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Thu, 07 Sep 2017 16:49:36 +0200 In-Reply-To: (Jelle Licht's message of "Thu, 7 Sep 2017 00:56:41 +0200") Message-ID: <87o9qmtvgf.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27553-done Cc: 27553-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Heya! Jelle Licht skribis: > I just tested what Ludo' proposed, and it seems to work like a charm. > Seeing as we might be seeing more non-init shepherd instances w.r.t. > user services and the possible service extension to `guix environment', > I think it would be a good call to fix this bug :-). Indeed, thanks for the reminder. > From db942182224dfc0accad94897dd2122b128eef07 Mon Sep 17 00:00:00 2001 > From: Jelle Licht > Date: Thu, 7 Sep 2017 00:52:49 +0200 > Subject: [PATCH] Lazily register SIGCHLD hander on first call to > 'fork+exec-command'. > > * modules/shepherd.scm (main): Move unconditional top-level call to 'siga= ction' to... > * modules/shepherd/service.scm (fork+exec-command): here. Use new variabl= e. > (%sigchld-handler-installed?): New variable. LGTM, applied! Ludo=E2=80=99. ------------=_1504795802-5196-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 2 Jul 2017 01:11:17 +0000 Received: from localhost ([127.0.0.1]:48060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRTPx-0000jT-9n for submit@debbugs.gnu.org; Sat, 01 Jul 2017 21:11:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37277) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRTPw-0000jH-Ev for submit@debbugs.gnu.org; Sat, 01 Jul 2017 21:11:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRTPp-00071S-Tr for submit@debbugs.gnu.org; Sat, 01 Jul 2017 21:11:11 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:32768) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dRTPp-00071M-QM for submit@debbugs.gnu.org; Sat, 01 Jul 2017 21:11:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRTPo-000775-JG for guix-patches@gnu.org; Sat, 01 Jul 2017 21:11:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRTPn-000709-C2 for guix-patches@gnu.org; Sat, 01 Jul 2017 21:11:08 -0400 Received: from mail.fsfe.org ([2001:aa8:ffed::3:102]:33212) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dRTPn-0006zP-1k for guix-patches@gnu.org; Sat, 01 Jul 2017 21:11:07 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.fsfe.org (Postfix) with ESMTP id F20A46392C5 for ; Sun, 2 Jul 2017 03:11:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.fsfe.org Received: from mail.fsfe.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J2T+oZ2u9pk for ; Sun, 2 Jul 2017 03:11:04 +0200 (CEST) Received: by mail-it0-f50.google.com with SMTP id m84so41541116ita.0 for ; Sat, 01 Jul 2017 18:11:04 -0700 (PDT) X-Gm-Message-State: AKS2vOzN7mZHhnZmvYxn1eCTP0X4buHjenFk3r5LgdRA1niX4PLGWqMF b0QGSWAo8fN3VlyRxvpd74A5kX8Dpg== X-Received: by 10.36.41.138 with SMTP id p132mr26802999itp.49.1498957862079; Sat, 01 Jul 2017 18:11:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.172.66 with HTTP; Sat, 1 Jul 2017 18:11:01 -0700 (PDT) From: Jelle Licht Date: Sun, 2 Jul 2017 03:11:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: [PATCH shepherd] Register SIGCHLD handler after primitive fork To: guix-patches@gnu.org Content-Type: multipart/mixed; boundary="001a113f6a54e744a005534b5230" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -7.8 (-------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.8 (-------) --001a113f6a54e744a005534b5230 Content-Type: multipart/alternative; boundary="001a113f6a54e7449c05534b522e" --001a113f6a54e7449c05534b522e Content-Type: text/plain; charset="UTF-8" Hi all, I am not sure if this is also the proper ML for the GNU Shepherd, but looking in the archives lead me to believe it actually is. If not, I suggest the gnu.org page for shepherd be updated with the correct info. I recently starting playing around with user shepherd, and found out that when running a shepherd 0.3.2 daemonized as non-init process (via "(action 'shepherd 'daemonize)"), zombie processes are created whenever you start and subsequently stop any service. Thinking I did something wrong, I asked lfam on #guix to share his (very helpful) init.scm for user shepherd, yet I still noticed the same behaviour. I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f828db' inadvertently introduced an ordering issue, where the SIGCHLD handler is registered /before/ shepherd has the chance to daemonize. I believe the following trivial patch addresses this snafu. Regards, Jelle --001a113f6a54e7449c05534b522e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I am not sure if this = is also the proper ML for the GNU Shepherd, but looking in the archives lea= d me to believe it actually is. If not, I suggest the gnu.org page for shepherd be updated with the correct info.

I recently starting playing around with user shepherd, a= nd found out that when running a shepherd 0.3.2 daemonized as non-init proc= ess (via "(action 'shepherd 'daemonize)"), zombie process= es are created whenever you start and subsequently stop any service.
Thinking I did something wrong, I asked lfam on #guix to share= his (very helpful) init.scm for user shepherd, yet I still noticed the sam= e behaviour.

I believe commit `efa2f45c5f7dc735407381b7b8a83d6c37f82= 8db' inadvertently introduced an ordering issue, where the SIGCHLD hand= ler is registered /before/ shepherd has the chance to daemonize. I believe = the following trivial patch addresses this snafu.

Regards= ,
Jelle


--001a113f6a54e7449c05534b522e-- --001a113f6a54e744a005534b5230 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Register-SIGCHLD-handler-after-primitive-fork.patch" Content-Disposition: attachment; filename="0001-Register-SIGCHLD-handler-after-primitive-fork.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j4m0shec0 RnJvbSAyNjAzYTFmNDIwMTY2OGMxM2Y5OTJkYmRlM2RkNDZiZTRkYzJjMzFkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKZWxsZSBMaWNodCA8amxpY2h0QGZzZmUub3JnPgpEYXRlOiBT dW4sIDIgSnVsIDIwMTcgMDI6NTg6MzYgKzAyMDAKU3ViamVjdDogW1BBVENIXSBSZWdpc3RlciBT SUdDSExEIGhhbmRsZXIgYWZ0ZXIgcHJpbWl0aXZlLWZvcmsuCgoqIG1vZHVsZXMvc2hlcGhlcmQu c2NtIChtYWluKTogTW92ZSBjYWxsIHRvICdzaWdhY3Rpb24nIHNvIGRhZW1vbml6ZWQgcHJvY2Vz cwogIGNhbiBoYW5kbGUgU0lHQ0hMRCBzaWduYWwuCi0tLQogbW9kdWxlcy9zaGVwaGVyZC5zY20g fCA2ICsrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMo LSkKCmRpZmYgLS1naXQgYS9tb2R1bGVzL3NoZXBoZXJkLnNjbSBiL21vZHVsZXMvc2hlcGhlcmQu c2NtCmluZGV4IGY3YzE2OWQuLmRmYWU3ZDYgMTAwNjQ0Ci0tLSBhL21vZHVsZXMvc2hlcGhlcmQu c2NtCisrKyBiL21vZHVsZXMvc2hlcGhlcmQuc2NtCkBAIC0xNDIsOSArMTQyLDYgQEAKICAgICA7 OyBTdGFydCB0aGUgJ3Jvb3QnIHNlcnZpY2UuCiAgICAgKHN0YXJ0IHJvb3Qtc2VydmljZSkKIAot ICAgIDs7IEluc3RhbGwgdGhlIFNJR0NITEQgaGFuZGxlci4KLSAgICAoc2lnYWN0aW9uIFNJR0NI TEQgcmVzcGF3bi1zZXJ2aWNlIFNBX05PQ0xEU1RPUCkKLQogICAgIDs7IFRoaXMgX211c3RfIHN1 Y2NlZWQuICAoV2UgY291bGQgYWxzbyBwdXQgdGhlIGBjYXRjaCcgYXJvdW5kCiAgICAgOzsgYG1h aW4nLCBidXQgaXQgaXMgb2Z0ZW4gdXNlZnVsIHRvIGdldCB0aGUgYmFja3RyYWNlLCBhbmQKICAg ICA7OyBgY2F1Z2h0LWVycm9yJyBkb2VzIG5vdCBkbyB0aGlzIHlldC4pCkBAIC0xNjQsNiArMTYx LDkgQEAKIAkgICAgIChhcHBseSBmb3JtYXQgI2YgKGdldHRleHQgKGNhZHIgYXJncykpIChjYWRk ciBhcmdzKSkKIAkgICAgIChxdWl0IDEpKSkpCiAKKyAgICA7OyBJbnN0YWxsIHRoZSBTSUdDSExE IGhhbmRsZXIuCisgICAgKHNpZ2FjdGlvbiBTSUdDSExEIHJlc3Bhd24tc2VydmljZSBTQV9OT0NM RFNUT1ApCisKICAgICAod2hlbiAocHJvdmlkZWQ/ICd0aHJlYWRzKQogICAgICAgOzsgWFhYOiBU aGlzIHRlcnJpYmxlIGhhY2sgYWxsb3dzIHVzIHRvIG1ha2Ugc3VyZSB0aGF0IHNpZ25hbCBoYW5k bGVycwogICAgICAgOzsgZ2V0IGEgY2hhbmNlIHRvIHJ1biBpbiBhIHRpbWVseSBmYXNoaW9uLiAg V2l0aG91dCBpdCwgYWZ0ZXIgYW4gRUlOVFIsCi0tIAoyLjEzLjIKCg== --001a113f6a54e744a005534b5230-- ------------=_1504795802-5196-1--