timeout of ping
Peter Lundkvist
command? The reason is that the timeout of 10 seconds is long for me.
I know that there is a risk making the timeout sorter but I'll run
some tests to see what happens.
Regards Peter Lundkvist
Robert Carnegie
Pmfji, it's certainly(?) feasible to write a plain shell script that
starts ping and then kills it after, oh, five seconds. Actually, I don't
like to use the word "certainly" when there are so many smarter people
here. But I'm pretty sure I could do it in ksh, at least. Pretty sure...
Ping on Microsoft Windows apparently can have the timeout specified
as a command line option - not that that helps you, of course, unless
you can run it in Windows (MS-DOS) emulation on SCO. If ping on Linux
has this capability (I can't determine that), you conceivably could run
it on a SCO UNIX box with lxrun - or recompile it. For that matter,
www.fping.com might be useful if it's an open source project as I presume
- simply make your desired change to the source code and recompile ;-)
(I expect to die having never personally downloaded, edited and compiled
source code.) If it can change its default timeout, I don't see that
in the manpage - but I have a bad track record at comprehending manpages.
Cursory searches of the Web turn up other possibilities which you could
investigate further - specifically, running a ping version or an equivalent
analogue to ping in (1) Perl or (2) Java, if you happen to have Perl or
Java installed, or if you can arrange it.
http://www.rocketaware.com/perl/perldelta/Net_Ping.htm , without
thinking too much about it, seems to be talking about this. Someone
better informed is probably going to tell us how to do it in awk.
Depending on what you actually want to achieve right now - probably
something less than the full bewildering capability of ping - there
may be another way to do what you want. For instance, one or more of
the Java projects I glimpsed actually used the UDP echo service on the
remote server, because (their) Java wasn't allowed access to raw sockets
in order to construct and/or receive "real" ICMP ping. The downside is
that this only works with hosts that implement UDP echo; hosts which
are clients rather than servers on the network apparently leave out
this function.
The term "keyhole watcher" for software that periodically connects
and disconnects to particular ports on a set of remote servers,
just to check that the service that runs on that port is alive,
doesn't appear to be widely enough used (or perhaps widely enough
implemented) for a Google.com search for "sco unix keyhole" to
hit anything useful. Again, maybe someone did something in
Perl or Java...
I'm the kind of guy who would design a system for near-real-time
monitoring of which hosts are or aren't present on the network by
setting up a daemon that pings everything at once, in the background,
say once a minute or once in five minutes, temporarily logging the
result - and trusting that modern network bandwidth means that the
stern warnings in the "man ping" online manual page against over-use
don't count any more. To check whether host X is up or down, I'd
pop up the current log file of pings of host X: no wait. But if
you want a _professional_ solution, ask someone else ;-)
Robert Carnegie
Glasgow, Scotland
Bela Lubkin
Does `ping -i lessthan10seconds` not work for you?
>Bela<
Jean-Pierre Radley
I suspect he wants a quick test like 'ping -c 1' to finish more quickly
if it gets no answer. That command times out in ten seconds by default.
--
JP
Robert Carnegie
I have a first^Wsecond draft after all:
#!/bin/ksh
# saved as tmp/pingout R.Carnegie
# ping with timeout
DELAY=4
TARGET=$1
ping -c $DELAY $TARGET &
sleep $(($DELAY+1))
kill -2 $! # which of course refers to the last "&" process
# end of tmp/pingout
"kill -2" or "kill -INT" (OpenServer) is the change in second draft;
ping gives you the "statistics" at the end that way, but not from a
simple "kill". Of course the value of DELAY may be varied to taste.
Ideally, there would be two threads, each killing the other when it
finishes, but I'm not up to constructing that. Possibly involves
ksh job IDs.
Mr. Lundkvist expressed in e-mail reservations about using "kill"
routinely; is this wrong?
Robert Carnegie
Glasgow, Scotland
Peter Lundkvist
A quicker -c 1 is exactly what I want and in my SCO 5.0.4 the -i
option indicates the time between each ping.
Regards Peter
Bela Lubkin
Yes, I had confused myself on which flags were already implemented and
which I only wished I had implemented. The flag I meant to point him to
was "-w", which is not yet supported by any shipping OpenServer. Peter
is testing the implementation for me. The new flag, carped from BSD,
means "stop the whole ping session after this much time, regardless of
how many packets have been sent or received, or current success status".
5.0.6 has the "-o" flag which causes termination after any one reply
packet has been received; but of course that's no help if the pingee
isn't home.
>Bela<
peter.lundkvist
Robert Carnegie <rja.ca...@excite.com> wrote in message
news:f3f18bc0.0106...@posting.google.com...
First of all it seems that I've got the perfect solution since Bela Lubkin
send me a new "ping" executable. I'm testing it right now and it does what I
need. I will put it into "production" tomorrow. I'll get back with the
results.
Secondly I don't know if it's wrong to use kill like any other command. Well
it properly isn't but in my opinion process should run and terminate exactly
as they are supposed to do by the programmer who made them - who knows if
he/she cleans up if someone kills the process.
I admit that killing ping properly wouldn't hurt.
/Peter Lundkvist