[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fo
[bug#27553] [PATCH shepherd] Register SIGCHLD handler after primitive fork
Wed, 12 Jul 2017 23:34:10 +0200
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Jelle Licht <address@hidden> 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’s 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 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.)
Perhaps a solution would be to install the SIGCHLD handler lazily upon
the first ‘fork+exec-command’ 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.