From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dRTQh-0007Ha-L6 for guix-patches@gnu.org; Sat, 01 Jul 2017 21:12:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dRTQg-0007ST-EU for guix-patches@gnu.org; Sat, 01 Jul 2017 21:12:03 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:45383) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dRTQg-0007SF-B1 for guix-patches@gnu.org; Sat, 01 Jul 2017 21:12:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dRTQf-0000kT-V4 for guix-patches@gnu.org; Sat, 01 Jul 2017 21:12:01 -0400 Subject: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork Resent-Message-ID: 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) 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) MIME-Version: 1.0 From: Jelle Licht Date: Sun, 2 Jul 2017 03:11:01 +0200 Message-ID: Content-Type: multipart/mixed; boundary="001a113f6a54e744a005534b5230" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: 27553@debbugs.gnu.org --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--