1

I am working on an embedded Linux system, which uses kernel-5.10.24.
It uses busybox as init, and has other utilities in rootfs, including adbd.
I can run adb shell from PC to login to the embedded system, then I started a shell script to do something in a loop.

But I found that when I type ^C to interrupt the script, it failed. I have to use ^Z first, then kill -9 xxx to stop the script running.

When the process is stopped by ^Z, it read its /proc/pid_of_script/status, I found followings,

SigPnd: 00000000000000000000000000000000
ShdPnd: 00000000000000000000000000020000
SigBlk: 00000000000000000000000000020000
SigIgn: 00000000000000000000000000001006
SigCgt: 00000000000000000000000000020000

The SigIgn masked the SIGINT (2). Then I checked its parent process and the grand-parent process (adbd), I found they all ignore SIGINT from their signal processing.

The adbd is started by /etc/init.d/rcS, which calls S50usb (S50usb also calls another script).

Then I changed to start S50usb in /etc/inittab after shell is running. But I got the same result as before.

I wonder if there is a way in run-time to adjust the script process's SigIgn, then SIGINT can stop its running?

wangt13
  • 429
  • 1
    it appears as though SIGQUIT is also ignored.. is your rcS possibly launching adbd in the background as in adbd & ? – LL3 Apr 26 '23 at 07:23
  • Oops, you are right, the S50usb will start adbd &, so that is why SIGINT is ignored, since there is no controll terminal for it, right? – wangt13 Apr 26 '23 at 07:44

1 Answers1

1

Based on LL3's comment, and the answer to What's the difference between running a program as a daemon and forking it into background with '&'?I got the solution.
adbd is started by script with adbd &, which put it into background.
As a background process, adbd has been set to ignore SIGINT.
The solution might be using start-stop-daemon script to launch adbd in the script, instead of using adbd & directly.

wangt13
  • 429
  • Quite correct. Note that both SIGINT and SIGQUIT are ignored. start-stop-daemon would make your Ctrl-C work but does not provide auto-respawn. Perhaps you might try and split your app so as to move its initial operations (those that truly need to be run early on) into rcS while keeping its long-running operation in inittab:respawn. rcS (i.e. what lies in sysinit) is typically meant to perform one-off bootstrap operations – LL3 Apr 26 '23 at 14:38
  • You are right on the process life-cycle management, I had another question on it https://unix.stackexchange.com/questions/743389/how-to-start-and-manage-a-process-in-busybox-inittab-and-rcs-as-early-as-possib. Putting process in rcS make it started earlier than in inittab, but lost the respawn property. So I found a way to solve it by starting a wrapper script of long-run process in rcS which has a loop to start the real process. It worked fine if the process is running in foreground, but does not work for daemon, welcome any ideas on this. – wangt13 Apr 26 '23 at 23:53