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.
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/
