[Bug 5564] New: ash does not handle terminating signals correctly

bugzilla at busybox.net bugzilla at busybox.net
Sat Sep 22 10:30:00 UTC 2012


https://bugs.busybox.net/show_bug.cgi?id=5564

           Summary: ash does not handle terminating signals correctly
           Product: Busybox
           Version: 1.19.x
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Standard Compliance
        AssignedTo: unassigned at busybox.net
        ReportedBy: tj.groenen at gmail.com
                CC: busybox-cvs at busybox.net
   Estimated Hours: 0.0


Created attachment 4562
  --> https://bugs.busybox.net/attachment.cgi?id=4562
Two patches to implement the mentioned signal handler in ash

There seem to be two bugs in ash with regards to handling terminating signals.
1) When launching an application in the background from a shell, it won't get
SIGHUPped when the parent shell receives a terminating signal.
2) When ash receives a terminating signal it won't call exitshell(), resulting
in its history not being written out when FEATURE_EDITING_SAVE_ON_EXIT is set.

Bash fixes these two issues by installing a signal handler for all terminating
signals. Also see sig.c in the bash source, search for terminating_signals[]
for
the complete list of terminating signals and termsig_handler for the handler.

Attached are two patches that'll introduce a similar signal handler for ash.
The
signal handler re-uses pkill* to signal children and exits the shell cleanly
afterwards. Pgrep had to be patched slightly to allow it to be called from
other
applets. The signal handler is installed only for SIGHUP when ash is
interactive, but this can be extended easily to more terminating signals.

My main concerns with it at the moment are the use of unsafe functions in the
signal handler. However, as far as I can see, bash calls (indirectly) large
amounts of code from their terminating signal handler as well, though I haven't
done an extensive code analysis. I'm not sure what the negative implications
are
of my (or their) code wrt shell applications, so all feedback is much
appreciated.

* Calling kill() or killpg() instead of re-using pkill did not result in the
loop application being killed as in the steps to reproduce below.

---Steps to reproduce (busybox 1.20.2)
Note: loop is a C application that simply loops forever
[term1 ~] busybox ash
[term1 ~] echo $$
19619
[term1 ~] ./loop &

[term2 ~] pstree -p 19619
busybox(19619)---loop(19624)
[term2 ~] kill -1 19619
[term2 ~] pidof loop # loop does not get killed
19624
[term2 ~] cat ~/.ash_history # shell does not exit cleanly, e.g. no history
cat: /home/dennis/.ash_history: No such file or directory

--Expected results (bash 4.2.37-2)
Note: loop is a C application that simply loops forever
[term1 ~]$ bash
[term1 ~]$ echo $$
19561
[term1 ~]$ ./loop &
[1] 19562

[term2 ~]$ pstree -p 19561
bash(19561)---loop(19562)
[term2 ~]$ kill -1 19561
[term2 ~]$ pidof loop # loop gets killed
[term2 ~] cat ~/.bash_history | tail -2 # history gets saved
echo $$
./loop &

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the busybox-cvs mailing list