On 8/9/06, Matthew Soffen <[EMAIL PROTECTED]> wrote:

 Morning all.

 This does appear to run cleanly on FreeBSD.

 As for what triggered me looking into this, the BasicSanityCheck .  It is
now passing up to the where it runs STONITHDBasicSanityCheck.  Now to figure
out what is causing it to fail there.

does FreeBSD support farside_pid?  If not, BSC wont pass until
bugzilla 1381 is resolved.


 There  also seems to be something tied to a "reboot" command ( that is
using Linux parameters).    This is from my /var/log/messages file.
      reboot: illegal option -- f
      usage: reboot [-dlnpq] [-k kernel]

 Matt


 David Lee wrote:
 On Wed, 9 Aug 2006, Andrew Beekhof wrote:



 On 8/9/06, Horms <[EMAIL PROTECTED]> wrote:


 David Lee <[EMAIL PROTECTED]> wrote:


 If all the above is correct, wouldn't the function be clearer as:

 # copy stdin (text) to FIFO, with surrounding ">>>" and "<<<" marker lines.
 # no args.; no result
 ha_clustermsg() {
 echo ">>>" >> $HA_FIFO
 cat - >> $HA_FIFO
 echo "<<<" >> $HA_FIFO
 }

or:
 # copy stdin (text) to FIFO, with surrounding ">>>" and "<<<" marker lines.
 # no args.; no result
 ha_clustermsg() {
 (echo ">>>"; cat -; echo "<<<") >> $HA_FIFO
 }

or similar?

(Note that the "cat -" could be reduced to "cat". But for clarity I
prefer the "cat -" version, which makes explicit to the maintainers the
intention to use stdin as the data source. Clarity again.)

Matt; LMB; others: thoughts?

 Any variation on that theme is fine by me.
Any time I see `...` inside a here-doc I start to become squeamish.

Actually, for what its worth, I prefer the first version,
it seems clear, and newlines are not a scarce resource.

 agreed


So I think we're agreed on the principle of rewriting it.

But since my earlier email a further thought has crossed my mind about the
merits of:
 thing1 >> fifo
 thing2 >> fifo
 thing3 >> fifo
vs:
 (thing1; thing2l thing3) >> fifo

The first does three sets of open/close operations, the second does
only one. Efficiency.

Also each operation may have potential "end-of-data" or "flush" semantics
on the fifo, whereas the second does all these as a single set.

This is probably not sigificant. But if it is (or if there is a future
chance of its becoming significant) then the second version (the single
parenthesised subshell into a single call to the fifo) may be preferable.

I'll prepare a local-workspace patch for the:
 (thing1; thing2l thing3) >> fifo
variant and apply it post-2.0.7 shipment.

Of course if someone else wishes to do this (especially if Matt confirms
that this fixes his problem) they are welcome to do so!

(Can anyone confirm that it doesn't introduce new breakage into a Linux
installation?)





_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/



_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to