David Lee wrote:
> On Fri, 20 Apr 2007, Alan Robertson wrote:
>
>> David Lee wrote:
>>> On Thu, 19 Apr 2007, Xinwei Hu wrote:
>>>
>>>> [David Lee had earlier written:]
>>>>> 5. "ping -q -c 1 $ping_host". The options for "ping" are notoriously
>>>>> variable from system to system. Keep it simple. (For example my system
>>>>> doesn't have a "-q" option; and it says that "-c <n>" is for a thing
>>>>> called "traffic class", only valid on IPv6.) If they are not necessary,
>>>>> leave them out. If they are necessary, then for those of us who come
>>>>> along later to maintain code, especially on other operating systems, it is
>>>>> worth adding comments about your intentions, such as:
>>>>> # -q: to do foo
>>>>> # -c <n> to do bar
>>>> Here on my system:
>>>> -c count
>>>> Stop after sending count ECHO_REQUEST packets. With
>>>> deadline
>>>> option, ping waits for count ECHO_REPLY packets, until the
>>>> time‐
>>>> out expires.
>>>> -q Quiet output. Nothing is displayed except the summary lines
>>>> at
>>>> startup time and when finished.
>>> "ping" on Linux and Solaris (to name two of our OSes) seem incompatible in
>>> their options.
>>>
>>>> -q can be removed as we did ">/dev/null 2>&1" already.
>>> Yes. The ">/dev/null 2>&1" method is the way to go to suppress output
>>> across a range of OSes
>>>
>>>> -c is used so that ping won't last forever.
>>> On Solaris: "ping hostname [data_size ] [ count ]"
>>>
>>> In practice, it seems that "ping hostname number" also causes a swift
>>> return for non-replying hosts.
>>>
>>> See "resources/heartbeat/IPaddr.in" and "resources/OCF/IPaddr.in" which
>>> tryi to do the right thing according to which OS they are running on.
>>>
>>> So it might be worth us trying to develop our own "ping-wrapper" command
>>> with a fixed, portable, interface, whose contents are based on those in
>>> those other two files, and which they would then use, and which your new
>>> "pingd" could also use.
>> [...]
>> Of course, we already have portable ping code in C in our base. The
>> best way to do this portably is probably to use that code, which is
>> guaranteed not to change without us knowing about it...
>
> Alan: The context of this discussion is for callers that are shell-scripts
> (the proposed "pingd.sh"; also noting two "IPaddr.in") rather than C code.
>
> The principle of calling the system "ping" is clean and simple -- far more
> so (isn't it?) than having to (re-)write a ping-like command to call the C
> code in our base.
I knew the context ;-). There is a bit of devil's advocate in my blood
I confess ;-).
My experience is that the autofoo commands work really well for C, and
less well so for shell scripts. And, what's the big difference between
calling a system binary we have no control over versus one of our own
that we do have control over?
> The current problem is simply that the system "ping" in different OSes has
> different options, and the current discussion is about how to handle that.
And some OSes provide options that others don't. Not just that they
need different flags.
> So I'm wondering whether, in the case of script-based (not C) callers, we
> could simply have a shell function (e.g. "pingfn") with a fixed interface
> acting as a wrapper to the system-shell ping command and handling all the
> relevant OS incompatibilities.
One could certainly do that. It would have to detect at run time which
thing to do. Or I suppose one could have something like this:
if test "we are on solaris"; then
ourping() {
}
else if test "we are on linux" then
ourping() {
}
Or one could use autofoo to detect which options we need and pass them
through all the autofoo stuff to the script.
Any of those would work...
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
