Solaris 11 Zones iostat problem
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 <Nick at Pettefar.com> wrote:
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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 2 October 2014 02:46, Richard L. Hamilton <rlhamil2 at gmail.com> wrote:
if [ -x /usr/bin/zonename ] && [ x”
/usr/bin/zonename” = x”global” ]
(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)
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: 919-861-1247 | Mobile: 919-622-5369 | Fax: 919-861-1300
On Fri, Oct 3, 2014 at 2:31 AM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On 2 October 2014 02:46, Richard L. Hamilton <rlhamil2 at gmail.com> wrote:
if [ -x /usr/bin/zonename ] && [ x”
/usr/bin/zonename” = x”global” ](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)
I could be wrong, but I don't know of any shell that would misinterpret a dash or equals when inside double quotes.
J
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 3 October 2014 22:45, Steve Coile <scoile at mcclatchyinteractive.com> 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
it's very unlikely to have any practical effect. I use Richard's approach myself. You should, too. :)
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
participants (4)
-
jlaidman＠rebel-it.com.au
-
Nick＠pettefar.com
-
rlhamil2＠gmail.com
-
scoile＠mcclatchyinteractive.com