Terry L. Inzauro wrote:
> 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 ;)
I was assuming that one would use configure to detect which ping
arguments do what - at least to the degree possible using autoconf. We
already do that in other places. But, it's a pain. There are lots of
good tests for C code, and for shell script things like this you
typically have to write your own tests, and then debug them on every
platform - which is kind of annoying.
--
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
