Solaris 11 Zones iostat problem 🔗 link

We are having problems with our Solaris 11 zones; iostat takes a long
time and uses considerable CPU when run on the zones so for the
interim we want to disable it.  What is the best/easiest way to do
this please?  (iostat on the global behaves normally.)

Regards,

Nick Pettefar

Don’t know for “best”, but to me the most obvious way is to edit client/bin/xymonclient-sunos.sh, to only run the iostat commands on the global.  Those commands are somewhere around lines 165 and 166.  You might want to see if its only the CPU or only the disk related command that is the problem rather than necessarily both.  Further down, where the files they create are used, that only happens if the files exist; so you only need to make the change around 165-166, not further below too.

An IMO reasonable test if on the global might look like:

if [ -x /usr/bin/zonename ] && [ x”`/usr/bin/zonename`” = x”global” ]
then
#  commands to run only on global
fi

(the x in front of the strings being compared is just paranoia against one of them having a syntactically confusing value, like a dash option or an = sign)

On Oct 1, 2014, at 7:33 AM, Nick Pettefar <user-2027539dd102@xymon.invalid> wrote:

On 2 October 2014 02:46, Richard L. Hamilton <user-af55987f6d56@xymon.invalid> wrote:

if [ -x /usr/bin/zonename ] && [ x”`/usr/bin/zonename`” = x”global” ]

I could be wrong, but I don't know of any shell that would misinterpret a
dash or equals when inside double quotes.

J

Suppose /usr/bin/zonename returned "-f", producing:

[ -f = global ]

which would fail because "=" likely isn't a filename, a test for the
existence of a file by that name likely isn't anywhere close to what you
want to do, and "global" would be an unrecognized argument.

Richard's approach is a good one in the general case, even if in this case
it's very unlikely to have any practical effect.  I use Richard's approach
myself.  You should, too.  :)


-- 

*Steve Coile*Senior Network and Systems Engineer, McClatchy Interactive
<http://www.mcclatchyinteractive.com/>;
Office: XXX-XXX-XXXX | Mobile: XXX-XXX-XXXX | Fax: XXX-XXX-XXXX

On Fri, Oct 3, 2014 at 2:31 AM, Jeremy Laidman <user-71895fb2e44c@xymon.invalid>

wrote:

On 3 October 2014 22:45, Steve Coile <user-a2e2f9aff0d1@xymon.invalid>
wrote:

Suppose /usr/bin/zonename returned "-f", producing:

[ -f = global ]

No, it would produce:

[ "-f" = "global" ]

which would fail to match of course, but would not produce a parsing
mistake, which I assume is the reason for the "x" prefix.  The "-f" would
not cause the shell to test for the existence of a file.

Actually, even an unquoted "-f" doesn't seem to fail to parse in this way.
A better test is to use "-eq", like this:

$ [ `echo 0 -eq` = "global" ] && echo true || echo false
-bash: [: =: integer expression expected
false

$ [ "`echo 0 -eq`" = "global" ] && echo true || echo false
false

The first example triggers the type of parsing problem that I think you are
referring to, and trying to protect against.  The second one, with the
double quotes around the expression, eliminates the problem.

Richard's approach is a good one in the general case, even if in this case

Richard's way works, so that's fine.  As a matter of style, I don't like it
because it's not clear what it's trying to do, and distracts from the
readability of the code.  The fact that Richard felt he needed to explain
the reason for the "x" reinforces my view on this.  I won't be using the
this technique; and instead, for improved readability I'll continue to
recommend that people rely on double quotes.

Cheers
Jeremy

Thanks for all your input.  Appreciated.

Incidentally, zonename produces either "global" or a zone name so not
sure what all the scripting argument is all about.  Maybe I lost the
plot somewhere or other.

[ $(zonename) != "global" ] && [ $(uname -r) = "5.11" ] && echo
"Solaris 11 zone, best not use iostat and vmstat."

Oracle are looking into why Solaris 11 zones go funny with iostat and vmstat.

Nick
Dublin