[Xymon] mq.sh script

[Jeremy Laidman]

Neil

I can confirm that I can replicate this behaviour when sending a xymon
"client" message using the command structure in the script, and it is
returning the relevant section of client-local.cfg. This is the expected
and documented behaviour of the "xymon client" command - see man(5)
client-local.cfg for info about how this works with the client message.

Interestingly. your script is using the "testname is mqcollect" way to
specify a collector ID. Newer versions of the mq.sh script doesn't rely on
this special behaviour, and instead sets the collector ID by suffixing the
"client message type with the collector ID, using this line:

echo "client/mqcollect $MACHINE.mqcollect mqcollect" >$TMPFILE

You seem to be using a script that's likely more than 10 years old. I
recommend upgrading if you can.

And I suspect this is the crux of the problem, in that the script was
written when xymond didn't give a response to a xymon client command. That
was a long time ago.

Although I doubt the age of the mq.sh script is causing any issues for you,
and certainly shouldn't be the cause of the inappropriate lines in the
logfile. My copy of mq.sh, from Xymon 4.3.10, has the same problem.

A solution to this is for this script to use "-" instead of "@" in the
xymon command, and in doing so, have the received output discarded (it's
still received, but xymon doesn't present it on STDOUT), like so:

$XYMON $XYMSRV "-" < $TMPFILE

Another option would be to simply redirect STDOUT to /dev/null:

$XYMON $XYMSRV "@" < $TMPFILE >/dev/null

This will still log anything that is sent to STDERR. As we would not expect
any output, unless there was a problem, dumping all standard output is
unlikely to have any negative consequences. Personally, I prefer the "-"
solution.

Cheers
Jeremy

On Tue, 28 Jul 2020 at 23:58, Neil Simmonds <neilsimmonds1808 at gmail.com>
wrote:

> I've already tried running it with a set -x in the script and get the
> following in the log,
>
> + rm /xymon/client/tmp/mq-server_name.11677
> + TMPFILE=/xymon/client/tmp/mq-server_name.11684
> + touch /xymon/client/tmp/mq-server_name.11684
> + echo 'client server_name.mqcollect mqcollect'
> + '[' 1 '!=' 0 ']'
> + QMGR=PPIM01
> + shift
> + sudo -u mqm mqsc PPIM01 'display qstatus(*) curdepth msgage lgetdate
> lgettime'
> + '[' 0 '!=' 0 ']'
> + /xymon/client/bin/xymon ukclamon01 @
> log:/opt/IBM/MDMPIM/logs/workflowengine_server_name/db_manager.log:10240
> log:`find -L /opt/IBM/MDMPIM/logs/\w*server_name/\w*.log -maxdepth 1
> -type f ! -size 0`:10240
> log:/applogs/mdmpim/logs/appsvr_server_name/default.log:10240
> log:/opt/IBM/MDMPIM/logs/workflowengine_server_name/customegl.log:20480
> log:/opt/IBM/MDMPIM/logs/workflowengine_server_name/default.log:20480
> ignore INFO
> trigger internal error
> file:`find /applogs/mdmpim/dump -name *.txt`
> file:`find /applogs/mdmpim/dump -name *.phd``
>
> From there I can see that it appears to be the line that sends the message
> to Xymon that's doing it but U can't see why.
>
> The line in question is underlined and BOLD below (copied the whole script
> for context)
>
>
> TMPFILE="$XYMONTMP/mq-$MACHINE.$$"
>
> touch $TMPFILE
>
> echo "client $MACHINE.mqcollect mqcollect" >$TMPFILE
>
> #
> while [ $# != 0 ]
> do
>     QMGR=$1; shift
>     sudo -u mqm mqsc $QMGR 'display qstatus(*) curdepth msgage lgetdate
> lgettime' >> $TMPFILE
>     ##(echo 'dis ql(*) curdepth'; echo 'dis chs(*)'; echo 'end') | su -
> mqm -c "runmqsc $QMGR" >> $TMPFILE
> done
> #
>
> *$XYMON $XYMSRV "@" < $TMPFILE*
> rm $TMPFILE
>
> exit 0
>
>
>
>
> On Mon, Jul 27, 2020 at 5:54 PM Damien Martins via Xymon <xymon at xymon.com>
> wrote:
>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Damien Martins <damien at makelofine.org>
>> To: xymon at xymon.com
>> Cc:
>> Bcc:
>> Date: Mon, 27 Jul 2020 18:44:19 +0200
>> Subject: Re: [Xymon] mq.sh script
>>
>> Hello,
>>
>> I'm not using this script, but you may run it using:
>>
>> bash -x  $XYMONCLIENTHOME/ext/mq.sh queuemanagername
>>
>> replace $XYMONCLIENTHOME with the correct path.
>>
>> Bash will generate output debug info, so you may see what it is doing.
>>
>> Also, you may check if the log destination is hardcoded in the script.
>>
>>
>> Le 27/07/2020 à 16:39, Neil Simmonds a écrit :
>>
>> Hi all, I'm seeing some really strange behaviour from the MQ.SH script/
>>
>> We have the standard mq.sh script that comes with Xymon and we have it
>> setup in /xymon/client/etc/clientlaunch.cfg as follows
>>
>> [mq]
>>         ENVFILE $XYMONCLIENTHOME/etc/xymonclient.cfg
>>         CMD $XYMONCLIENTHOME/ext/mq.sh queuemanagername
>>         LOGFILE $XYMONCLIENTLOGS/xymonmq2client.log
>>         INTERVAL 1m
>>
>> The behaviour that we are seeing is that,as expected MQ.SH writes nothing
>> in the way of errors into xymonmq2client.log but what it does write into
>> there is the contents of /xymon/client/tmp/logfetch.hostname.cfg
>>
>> (i.e.
>> log:/applogs/broker/broker.log:20480
>> ignore MARK
>> )
>>
>> I'm at a loss to explain this so am reaching out to the list to see if
>> anyone has come across this
>>
>> Regards,
>> Neil.
>>
>> _______________________________________________
>> Xymon mailing listXymon at xymon.comhttp://lists.xymon.com/mailman/listinfo/xymon
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Damien Martins via Xymon <xymon at xymon.com>
>> To: xymon at xymon.com
>> Cc:
>> Bcc:
>> Date: Mon, 27 Jul 2020 18:44:19 +0200
>> Subject: Re: [Xymon] mq.sh script
>> _______________________________________________
>> Xymon mailing list
>> Xymon at xymon.com
>> http://lists.xymon.com/mailman/listinfo/xymon
>>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20200729/6df467f6/attachment.htm>