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. 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. 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. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
