First off, my apologies for the long overdue reply. Various other things have demanded my attention, and I wanted to have the time to make sure I had given it a good honest effort before I reported back. The story is a success by the way.
@zentara – Thanks for the reference to the thread->kill feature. It was most helpful. I ended up going with your suggestion of killing tcpdump by its pid because I couldn't seem to end the thread without tcpdump first ending (I/O operation).
@juster & BrowserUK– I now see I have a SIGALRM fail on my part. The clarification was helpful. Arping unfotunately won't work for what I've been assigned to accomplish. Arping works on the subnet and for its part work well. Two problems I see using it (if my understanding is correct), is it relies on a cache which means for some reason or other, I won't always have valid information (especially since DNS management is also bad here), but also arping doesn't reach across routers. If the DNS does not apply to anything locally I still need to know if it being used elsewhere so I can don't mark it as unused.
@BrowserUK – I read everything you wrote and found A LOT of mistakes in what I coded up. Trying to answer your questions made me realize that some of my code was more wishful thinking than an actual solution. This was also evident in your use of the word “hope” in most of those questions.
Now that I almost have my head screwed on straight, let me re-clarify the problem, the reason tcpdump needs to be part of the solution, and what my solution is (although it needs some tuning still).
Problem: We need to know the location of various Virtual Machines in case they go down. Unfortunately there has been no solid naming convention and so there is a lot of confusion as to where a given virtual machine might be. Instead of taking the time to fix the naming convention I've been assigned the less efficient although quite educational task of writing a script to determine what virtual machines are running on each host.
Soltion: After doing some voodoo to determine possible DNS names of the Virtual Machines located on a host, I try and ping them. A ping alone will not give me my answer as the DNS name may be associated with some other server located elsewhere on the network. When I use tcpdump I can listen on the hosts eth0 interface for incoming packets. All packets going to the virtual machines are routed through eth0. So by starting an instance of tcpdump and sending some pings through, I can be sure that that DNS is associated with a virtual machine on that host. Then I can update the location (host) of that virtual machine in the database.
Code (As you can see it's far more simplified and makes much more sense. At least to me. And it has been working.):... my $dump_thread = threads->new(\&tcp_dump, $macaddress, $dns_name); sleep 1; my $ping_thread = threads->new(\&ping, $dns_name); ... $ping_thread->join(); ... // this section checks if tcpdump captured a packet and does something + with it ... my $dump_pid = `pidof tcpdump`; `kill $dump_pid`; $dump_thread->join(); ...
Notes: I had to kill the tcpdump process in order to end the thread because it's considered an I/O operation (particulars for this have already been described above). After I completed that I was free to join the thread.
No the thread for my ping operation isn't necessary. I set a timeout as well as a 2 ping count so no matter what it will end. I went back to fix it, but I posted it here, so maybe it'll serve some benefit to someone else.
Thank you all for all of your replies and references. They were very helpful and I picked up a lot and now know at least a small bit of PERL kung fu.
In reply to Re^2: Threads, bash, and networking
by morganda
in thread Threads, bash, and networking
by morganda
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |