bug in 2.4.22: process left in 'T' state.
From: Tigran Aivazian
Date: Wed Dec 03 2003 - 10:17:19 EST
I just noticed a very interesting behaviour which I haven't seen before.
I think it's a bug and very easily reproducible one too.
I was running in one session:
# tcpdump -i lo icmp
and in another session:
# strace -p 2117 -v
(2117 being the pid of tcpdump).
and in yet another session:
# ping -c 1 localhost
Now, after tcpdump captured the two icmp packets I waited until strace
showed it blocked in the next recvfrom() system call and pressed ^C to
terminate strace. It did terminate, but it left tcpdump in the 'traced'
state and I couldn't do anything to kill tcpdump from within (i.e. all
SIGINTs were blocked).
Re-running strace -p 2117 -c caused this:
~# strace -p 2117 -v
--- SIGINT (Interrupt) ---
and in the tcpdump session:
~# tcpdump -i lo icmp
tcpdump: listening on lo
15:07:09.442309 localhost.localdomain > localhost.localdomain: icmp: echo request (DF)
15:07:09.442372 localhost.localdomain > localhost.localdomain: icmp: echo reply
+ Stopped tcpdump -i lo icmp
tcpdump -i lo icmp
2 packets received by filter
0 packets dropped by kernel
The two empty lines are my attempts to ^C which were ignored. Then, after
I re-run strace tcpdump was stopped and then bringing it to foreground
caused the SIGINT to be delivered and terminated as expected with the
packet count/loss reported as normal.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/