From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVPHl-0003vW-BS for guix-patches@gnu.org; Wed, 12 Jul 2017 17:35:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVPHi-0003TC-6f for guix-patches@gnu.org; Wed, 12 Jul 2017 17:35:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:33218) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVPHi-0003SI-3E for guix-patches@gnu.org; Wed, 12 Jul 2017 17:35:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dVPHh-0007Xj-Q2 for guix-patches@gnu.org; Wed, 12 Jul 2017 17:35:01 -0400 Subject: [bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Jelle Licht Cc: 27553@debbugs.gnu.org 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.