Re: Possible busy-loop in signal handling with a trap calling an external command

Chet Ramey <[email protected]> Fri, 24 Apr 2026 09:49:18 -0400

Newsgroups	gmane.comp.shells.bash.bugs
Organization	ITS, Case Western Reserve University
Message-ID	<[email protected]>

On 4/22/26 5:30 AM, František Šumšal wrote:

> Bash Version: 5.3
> Patch Level: 0
> Release Status: release
> 
> Description:
> Hello! Recently I was debugging a very strange fail in our systemd test suite, and after some digging I noticed it was
> caused by a bash script that was being used as a stub init for a test container. To test if the signal delivery to the
> container's init works properly, the stub init has several traps defined for various signals, which are then probed and
> checked. However, in a couple of cases the stub init entered a busy loop and trashed the machine. A minimized version
> of the stub init can be found in the Repeat-by section below.

Thanks for the detailed analysis and fix. Your fix is the simplest way to
solve this problem.

>     - (!!) run_interrup_trap() unconditionally resets catch_flag to 0 even though we still have a pending signal (SIGNAL2)

This is the issue. catch_flag is a semaphore indicating we have a pending
trap to execute. run_interrupt_trap() shouldn't reset it to 0 because we
don't go through all the signals.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc (application/pgp-signature, 203 B)