0000659: msh sends cntrl-C to background processes

BusyBox Bug and Patch Tracking

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0000659

[BusyBox] Other

major

always

01-25-06 11:09

05-05-06 11:39

Reporter

rgetz

View Status

public

Assigned To

BusyBox

Priority

normal

Resolution

fixed

Status

closed

Product Version

1.00

Summary

0000659: msh sends cntrl-C to background processes

Description

This bug was oringally reported as a bug in the signal handling code of Blackfin's uClinux port:
http://blackfin.uclinux.org/tracker/index.php?func=detail&aid=1031&group_id=17&atid=141 [^]

but was tracked down to this:

In our system, when using busybox 1.0, when using the msh shell, we see the following issue - CNTRL-C is sent to all processes started from the same term (even in the process is run in the background with "&"). To reproduce:

> ping 127.0.0.1 & [ starting ping in background ]
> ping 127.0.0.1

CTRL-C

On Desktop bash, and busybox ash &lash - this stops the foreground ping, and the one in the background keeps going.

In busybox msh and sash, background processes has the same PGID as TTY and will be interrupted by "ctrl-c" since the kernel sends the signal to every process with the same parent group IP number.

bash, ash, or lash assign a new group id to a background process. Most implemented in this way:
setpgid(child->pid, newjob->progs[0].pid);
Which sets the new background process's pgid identical to its pid, which make the process leader of a new process group, and will not be kill by ctrl-c.

I verified on the busybox mailing list that this was infact a bug in msh, and am posting it here.

-Robin

Additional Information

Since you can't see the pgid with busybox ps (hint, hint, nudge nudge), you can check it by looking at /proc/pid/status. For example, the /proc/43/stat (43 is the pid of the background ping) is:
43 (ping) S 23 23 23

According to ./linux-2.6.x/fs/proc/array.c: do_task_stat() the order of things is:
task->pid, tcomm, state, ppid, pgid,

23 is the pid of the shell.

You can look at all processes pgid by doing:
"cat /proc/*/stat | awk {'print $1"\t"$3"\t"$4"\t"$5"\t"$2'} | sort -n"
On my system, it gives something like (with ping running in the background):
pid, state, ppid, pgid, tcomm
1 S 0 0 (init)
2 S 1 0 (ksoftirqd/0)
3 S 1 0 (events/0)
4 S 1 0 (khelper)
5 S 1 0 (kthread)
6 S 5 0 (kblockd/0)
7 S 5 0 (pdflush)
8 S 5 0 (pdflush)
9 S 1 1 (kswapd0)
10 S 5 0 (aio/0)
11 S 1 1 (mtdblockd)
21 S 1 0 (inetd)
23 S 1 23 (sh)
24 S 1 24 (syslogd)
25 S 1 25 (klogd)
40 S 23 40 (dhcpcd)
97 S 23 23 (ping)
98 R 23 23 (cat)

and you can see why dhcpcd doesn't die - it changes the pgid itself, but
other applications (like boa, where the original issue was found) do not.

Attached Files

Relationships

Notes
(0001347) vapier 05-05-06 11:39	should be fixed now in trunk and the 1.1 branch

Issue History
Date Modified	Username	Field	Change
01-25-06 11:09	rgetz	New Issue
01-25-06 11:09	rgetz	Status	new => assigned
01-25-06 11:09	rgetz	Assigned To	=> BusyBox
05-05-06 11:39	vapier	Note Added: 0001347
05-05-06 11:39	vapier	Status	assigned => closed
05-05-06 11:39	vapier	Resolution	open => fixed