Hi, I have a shell script which uses tshark to monitor incoming video traffic, created by an ffmpeg process launched from the same script.
I want to capture until another process ends - so ideally until there has been a gap of X seconds since the last packet was captured. I can't find a way to specify this using parameters, but have managed to almost solve it by capturing the tshark pid, then killing it when the process it is monitoring ends.
This is not a problem on the face of it, since I capture the tshark PID at process start. However, when I do this the dumpcap process is often left running forever...
Any ideas how I can kill both tshark and the dumpcap process it has created...?
asked 14 Jun '17, 02:43
Do you need tshark decoding the incoming packets? If not - meaning you're only interested in capturing the packets, not any packet details during capture - you could just run dumpcap instead of tshark from your script and kill it instead directly.
answered 14 Jun '17, 02:47
While Jasper's answer is the better overall solution I'll try to answer the initial question.
tshark catches both SIGINT and SIGTERM and (tries to) clean up its child process (dumpcap) after catching those signals--so
You mention that it "often" doesn't work which is odd; I tried a few times here (with a fairly old version, no less) and it worked each time. There may be a problem lurking here but unless you're using a different signal (like SIGKILL) you were already killing tshark the "nice" way.
Actually it occurs to me that if you were using a signal other than SIGINT or SIGTERM then that could explain the behavior you were seeing: the SIGKILL would clearly kill tshark without allowing it to clean up dumpcap. Now IFF no more packets were received then dumpcap would hang around doing nothing. As soon as another packet is received, however, dumpcap will try to send a notification to tshark and should then get a SIGPIPE which would kill off dumpcap. (You mentioned that you were killing tshark after a test was completed which could mean "no more packets for a while.")
answered 14 Jun '17, 06:42
edited 14 Jun '17, 07:24