Alan Robertson wrote:
> 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...
>
>
>
would this logic be more suited at configure time than at run time? the
configure script could use
the build
host type to build OS specific ping code? that way, there's no issue when
building on different host
types.
it does, however, create OS/architecture dependent code that needs to be
created ;)
./configure
if test "we are on solaris"; then
build solaris specific ping code {
}
else if test "we are on linux" then
build linux specific ping code{
}
else if test "we are on osx" then
build osx specific ping code
}
just my $.02
_Terry
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
