Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!news.szaf.org!inka.de!mips.inka.de!.POSTED.localhost!not-for-mail
From: Christian Weisgerber <naddy@mips.inka.de>
Newsgroups: comp.unix.shell
Subject: Re: Cleaning up background processes
Date: Sat, 11 May 2024 14:30:42 -0000 (UTC)
Message-ID: <slrnv3v08i.17e3.naddy@lorvorc.mips.inka.de>
References: <slrnv3fm5e.jrj.naddy@lorvorc.mips.inka.de>
 <20240505214609.114@kylheku.com> <v1ah87$l0a8$1@news.xmission.com>
Injection-Date: Sat, 11 May 2024 14:30:42 -0000 (UTC)
Injection-Info: lorvorc.mips.inka.de; posting-host="localhost:::1";
	logging-data="41220"; mail-complaints-to="usenet@mips.inka.de"
User-Agent: slrn/1.0.3 (FreeBSD)
Bytes: 2889
Lines: 47

On 2024-05-06, Kenny McCormack <gazelle@shell.xmission.com> wrote:

> Having said that, I think we are all making our own assumptions about what
> the actual, underlying problem is.  Given that OP is not a newbie, it would
> help a lot if he would clarify what exact situation he is dealing with,
> rather than have us all guess (which is SOP when the poster *is* a newbie).

As part of a regression test suite, somebody wrote something like
this in a script:

        ./http-server &
        trap "kill %1" HUP INT QUIT PIPE TERM
        sleep 1 # server starts up

        [... Tests ...]

        kill %1
        wait %1 # wait for http-server

Using job control syntax in a noninteractive shell is already wrong,
although, to my surprise, it works as intended in common shells.

I've been looking at how to replace this with a portable-ish,
reliable-ish solution.  An obvious step is to use a standard
background process reference $! instead of job control %1.
Less obvious is the question how to deal with signals that abort
the script, without leaving background processes hanging around.

After remembering process groups, I thought I wouldn't need to trap
any signal at all, because common interruptions (hangup, intr, quit)
send signals to the whole group.  Then I discovered that FreeBSD
sh and bash start background processes with SIGINT ignored.  Sigh.
So I need to trap INT and convert it to some other signal.

Another complication is that the script is typically invoked from
make(1), so we have a make(1) process, an sh(1) process executing
the script, potential children, and the background process it spawned,
all in the same process group.  That means that the approach "trap
INT and manually signal process group" also signals make(1) with
whatever signal handling that carries.  And I haven't checked GNU
make yet.

I also had forgotten about "kill -<sig> 0" and was playing around
with "kill -<sig> -$$", which is wrong when make(1) is the process
group leader rather than sh(1).

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de