Hello,

I have a system where access to Linux shell is restricted so users cannot use tcpdump directly. As such I have a user interface which invokes tcpdump programmatically. This works, however when tcpdump is started via a system call I get 2 tcpdump processes, as shown below:

root 8173 6002 0 07:40 ? 00:00:00 /bin/sh -c tcpdump -s 1600 -w /mnt/core/ldap.pcap -i eth0?
root 8174 8173 16 07:40 ? 00:00:00 tcpdump -s 1600 -w /mnt/core/ldap.pcap -i eth0
root 8176 827 0 07:40 ttyS0 00:00:00 grep tcpdump

Can anyone tell me why 2 processes shows up instead of 1? And how to prevent it?

If I kill the 1 with the ? (pid 8173) at the end, the other one keeps running and capturing packets. If I kill the other tcpdump process (pid 8174) then both processes are killed, which seems backwards since 8174 is supposedly a child of 8173.

Perhaps in the end this is harmless since it appears that only 1 of them is actually capturing packets but I'd sure like to know why this happens.

Thanks much
Allen

Hi AllenMcw!

There could be various pieces of information which you might have been able to give us, that may have allowed us to better try to help you, from the mechanism of the restriction of access to tcpdump, to how the User Interface is implemented, and the column headers of what appears to be a ps command output.

Otherwise it would seem that we'd have to stack guesses on top of one another to try to help you.

I can tell you that if you use a non-interactive shell to run a command, unless you arrange to have things work in some other way, generally speaking the shell will wait for the command that it runs to finish running, then the shell will continue on to do whatever else it may need to do, and when nothing else remains for the shell to do, the shell will exit.

Killing the command that the shell ran would mean that command is no longer running, so if running that command was the only thing the shell had to do, the shell will exit.

There's nothing unexpected about that.

If the system call to which you refer did not start a shell, then there may be some issue. If there is such an issue, we'll likely need the additional details I've mentioned to be able to help you determine the cause of that issue.

HTH.

Hi Rigor,

Thanks. I did provide the ps command output in my opening post "ps -ef |grep tcpdump". It shows the two processes with the command line argument I supplied programmatically when I invoked the system command.

So literally I just programmatically called "system("tcpdump -s 1600 -w /mnt/core/ldap.pcap -i eth0)" The ps output immediately after shows the 2 processes. I am aware that this will wait until the command finishes before returning control to my application...this is actually what I want it to do. I am forking from the parent process and that child is the one which will wait until the system call comes back...again exactly what I want.

The question is why when I make the system call I just included above I immediately end up with 2 tcpdump processes instead of 1. The only thing unusual about the kill commands is that if I killed the child, both processes terminated but if I killed the parent only it died and the 2nd one continued running AND capturing packets.

Now another test I done was as follows:

I created a shell script with the following content:

#!/bin/sh

tcpdump $1

Then programmatically I called this shell script with the argument ("-s 1600 -w /mnt/core/ldap.pcap -i eth0") including the double quotes so it would take it as a single argument. tcpdump then runs and I get only ONE tcpdump process when I check ps output.

So there seems to be something about calling system directly that results in 2 processes.

In the end I can use the shell script wrapper to work around this but it would be nice to know why 2 tcpdump processes are created in the first example.

Thanks much
Allen

Hi AllenMcw,

WRT ps command output, what I indicated that you did not provide is the column headers from the ps command output. Your use of the grep command excluded the column headers from the ps command output.

If you believe that your original post shows 2 tcpdump processes, then you are mistaken. It does not show two tcpdump processes. What it shows is one /bin/sh process and one tcpdump process. If I tell the shell /bin/sh to run a simple sleep command in the background and further to run it in a sub-shell by running this command:

and on my system I then use the egrep command in a way that allows me to get the lines of ps command output that contain sleep 60 and also get me the ps command output column headers it looks like this:

but that ps command output does not show 3 sleep processes running, and it does not show 2 sleep processes running. It shows one /bin/sh process running, one sleep process running and one egrep process running.

HTH.

1 members found this post helpful.

If you want to avoid having that shell process stay around, make your callNow that shell will overlay itself with tcpdump, and you will have just one process.

1 members found this post helpful.

Thanks Rigor and Rknichlos. I should have realized that to start with.

All the best,
Allen