Also, Net::Ping::external is "alpha", and thus could be very buggy. And beware: Linux support for Net::Ping::external has some restrictions.

But he said ping works without the use forks module. The only thing I see in Net::Ping::external is that some status information is obscured. Nothing that would interact with forks.

---

s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}

On the failing system, what is the output from:

perl -e 'use forks; print system("ping -c1 localhost"),"\n$?\n";print 
+$! if ($?==-1)'
[download]

perl -e 'print system("ping -c1 localhost"),"\n$?\n";print $! if ($?==
+-1)'
PING localhost.tan.us (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.133 ms

--- localhost.tan.us ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.133/0.133/0.133/0.000 ms
0
0
[download]

Here the output on the failing system :



perl -e 'use forks; print system("ping -c1 localhost"),"\n$?\n";print 
+$! if ($?==-1)'<br/>

PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=0 time
+=0.036 ms

--- localhost.localdomain ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.036/0.036/0.036/0.000 ms, pipe 2
-1
-1
No child processes
[download]

That's what I thought. Threads is broke on your build of perl. Ping runs but system returns -1. You're going to have to recompile perl and have a look at the output from make.

---

s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}

"And going by your demonstration of the failure, the problem appears to clearly lie entirely within, or as a side effect of using the Forks module,..

Howerver I still have to desagree with him as to :

"...and I see no way that re-building perl would have any effect whatsoever."

Obviously there is some difference between your two systems and we still don't know what that difference is.

One thing I noticed, your perl was built with native threads. From your original post:

usethreads=define use5005threads=undef useithreads=define usemultiplicity=define

Which , at best, is redundant to the forks module and, at worst, is colliding with forks and causing your problem. (I can't confirm either way as I can't get the forks module to complete make test on my system.)

Look, I don't know how to fix your system. You have three choices.

starbolin++

However I still have to desagree with BrowserUk as to :

That's the problem with coming in half way through a thread and not fully reading back to the beginning--you (I) am apt to miss things.

You are right. If the machine had a non-threaded perl installed prior to the crash, (and if the The same little program works with the forks module on another server., is running a non-threaded version of perl), then that would be a good clue as to a conflict between Forks and threaded perl builds. Acquiring/building a non-threaded build of perl may well restore the function of the program.

I think using threads, or Net::Ping 'syn' mode is a better solution long term, but that's a personal choice.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.