Ash doesn't clear bb_got_signal for noninteractive shell

Seo Suchan via busybox <[email protected]> Fri, 12 Jun 2026 11:31:01 +0900
Newsgroups gmane.linux.busybox
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============8450244424656598732==
Content-Type: multipart/alternative;
 boundary="------------NPPWkmMEWU39npFaRIpd8UpG"
Content-Language: en-US, ko

This is a multi-part message in MIME format.
--------------NPPWkmMEWU39npFaRIpd8UpG
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

someone reported about bug in ash signal handling, which make long 
running script like mwan3 and acme.sh to hang to openwrt: 
https://github.com/openwrt/openwrt/issues/23745

from what I read it'd because bb_go_signal can set in noninteractive 
shell but only clears in interactive shell, make noninteractive shell to 
infinite loog to resolve already handled signal

Issue reporter suggests to clear bb_got_signal at start of do_trap() 
after it cleared pending_sig, and he claims to it solved it, but I 
didn't test if it would make new problem like clearling it too early

|--- a/shell/ash.c +++ b/shell/ash.c @@ -9608,6 +9608,9 @@ savestatus = 
status; } pending_sig = 0; +#if ENABLE_FEATURE_EDITING + bb_got_signal = 
0; +#endif barrier(); TRACE(("dotrap entered\n"));|


--------------NPPWkmMEWU39npFaRIpd8UpG
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>someone reported about bug in ash signal handling, which make
      long running script like mwan3 and acme.sh to hang to openwrt: 
      <a class="moz-txt-link-freetext" href="https://github.com/openwrt/openwrt/issues/23745">https://github.com/openwrt/openwrt/issues/23745</a></p>
    <p>from what I read it'd because bb_go_signal can set in
      noninteractive shell but only clears in interactive shell, make
      noninteractive shell to infinite loog to resolve already handled
      signal</p>
    <p>Issue reporter suggests to clear bb_got_signal at start of
      do_trap() after it cleared pending_sig, and he claims to it solved
      it, but I didn't test if it would make new problem like clearling
      it too early</p>
    <pre class="notranslate"><code class="notranslate">--- a/shell/ash.c
+++ b/shell/ash.c
@@ -9608,6 +9608,9 @@
 		savestatus = status;
 	}
 	pending_sig = 0;
+#if ENABLE_FEATURE_EDITING
+	bb_got_signal = 0;
+#endif
 	barrier();
 
 	TRACE(("dotrap entered\n"));</code></pre>
    <p><br>
    </p>
  </body>
</html>

--------------NPPWkmMEWU39npFaRIpd8UpG--

--===============8450244424656598732==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox

--===============8450244424656598732==--