Hi
The client only updates on slowscans – usually every 6 hours –
one of first lines in the logs will tell which scan number you
are on and which will be the next slow scan.
You can force a slow scan by stop/starting the service.
If you have waited more than 6 hours, then you have some other
issue – can you check the log on a slow scan? Usually easiest to
do this by stopping the service and then running the client
manually in a Powershell prompt.
Cheers
Zak
*From:*Kris Springer <user-c2caa0a7a8d5@xymon.invalid>
*Sent:* Wednesday, 20 February 2019 15:39
*To:* Beck, Zak <user-aada0fa38bf8@xymon.invalid>
<mailto:user-aada0fa38bf8@xymon.invalid>; Xymon MailingList
<xymon at xymon.com> <mailto:xymon at xymon.com>
*Subject:* [External] Re: [Xymon] Windows XymonPSClient v2.37
This message is from an EXTERNAL SENDER - be CAUTIOUS,
particularly with links and attachments.
I'm trying to remotely update a v2.28 client to the latest 2.37
version by following the instructions in the XymonPSClient.doc,
but the client isn't updating. Here's what I've done. Maybe I'm
missing something.
1. Download the latest xymonclient.ps1 from github and place it
in my server's scripts directory. (This is the directory where I
run other client scripts successfully)
2. Rename the xymonclient.ps1 file to xymonclient_2.37.ps1 (per
the doc instructions)
3. Get the md5sum of the file
4. Add the following line to the client-local.cfg file on the
server for the specific host I'm trying to update. (per the doc
instructions)
clientversion:2.37:https://my.domain.com/xymon/scripts:MD5:md5sumadlkfskdkfkfdl
<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.domain.com_xymon_scripts-3AMD5-3Amd5sumadlkfskdkfkfdl&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=05m99yiMkc-55R1AKXecttl5doV-7QYCPGCbqVr5S_s&e=>;
5. Check that the xymonclient_config.xml on the client has
<clientremotecfgexec>1</clientremotecfgexec>
When I look at the logs on the client it says it sees the
instruction from the server, but it doesn't perform any action.
The client version never changes.
Kris Springer
On 2/15/19 5:03 AM, Beck, Zak wrote:
Hi
I have committed v2.37 today, this has a big performance
related fix and other fixes – thanks to SebA
<user-4631430d620a@xymon.invalid <mailto:user-4631430d620a@xymon.invalid>> and Andy
user-982f5f6d4d28@xymon.invalid <mailto:user-982f5f6d4d28@xymon.invalid> for extra work
and prompting in this area.
Download from SVN
<https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_xymon_code_HEAD_tree_sandbox_WinPSClient_&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=L-dhmcu_CM75-ARQ7kmDxV7wP_abxGZqOuUDmZXC-RE&e=>;
(the documentation has been updated also, including uninstall
instructions).
The key fixes are:
* replaced WMI call to get number of processors with Windows
API call
The WMI call to get processor information was taking anything
from 4-5 seconds on most of my VMs, some experience much
longer waits and high CPU usage while this WMI call executed.
There have also been instances where the WMI call returns
incorrect data or no data. This has been replaced with a call
to GetNativeSystemInfo(), which should work on 32-bit and
64-bit platforms and in testing executes in milliseconds.
* only supply diskpart data if EnableDiskPart = 1
There is a test in the client which uses ‘diskpart’ to gather
information about clustering every slow scan. This is
included in the data sent to Xymon, but it’s not generally
displayed – you can extract it for reporting if needed.
Hardly anyone uses this and for some reason for some people
it is causing memory issues in the Microsoft Virtual Disk
Service. Therefore by default the test will now not be run,
you can enable it with the EnableDiskPart setting in
xymonclient_config.xml.
* add a dummy, ignored config item in the internal
client-local config table so that there is always some
configuration present (even if nothing in the server-side
client-local for this host)
We found that if there is no client-local.cfg for the host
and no default client-local.cfg (like [powershell] or
[XymonPS]), on some platforms there appears to be a memory
leak. The fix ensures there is always something in the
internal cache of client-config even if nothing is received
from the server.
* XymonAcceptUTF8 - default (0) is now to use the original
ASCII encoding, added setting for 'pure' ASCII coding which
strips/converts diacritic characters
Prior to this version, by default, the client uses ASCII
encoding to send to the server but also attempts to
encode/filter diacritic characters. This was added in v2.20,
and for some people it adds a large time overhead when
sending data.
It’s been changed so that the default setting of 0 acts like
it did before v2.20 – no diacritic encoding – I’m calling
this ‘original’ ASCII encoding. XymonAcceptUTF8 = 1 is
unchanged, uses UTF8. XymonAcceptUTF8 = 2 is the v2.20
setting, use ASCII and encode/filter diacritics – I’m calling
this ‘pure’ ASCII encoding. I don’t think this will impact on
many people other than saving time/cpu for the default setting.
Full changelog:
v2.37
* replaced WMI call to get number of processors with Windows
API call
* fixed servicecheck parentheses
* use TLS for uploading data to xymoncgi if using http
reporting and URL begins https
* add milliseconds to log timestamp
* add a dummy, ignored config item in the internal
client-local config table so that there is always some
configuration present (even if nothing in the server-side
client-local for this host)
* fix a couple of instances where we were using variables
before they are assigned
settings changes/additions:
* XymonAcceptUTF8 - default (0) is now to use the original
ASCII encoding, added setting for 'pure' ASCII coding which
strips/converts diacritic characters
* only supply diskpart data if EnableDiskPart = 1
Zak
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise confidential
information. If you have received it in error, please notify
the sender immediately and delete the original. Any other use
of the e-mail by you is prohibited. Where allowed by local
law, electronic communications with Accenture and its
affiliates, including e-mail and instant messaging (including
content), may be scanned by our systems for the purposes of
information security and assessment of internal compliance
with Accenture policy. Your privacy is important to us.
Accenture uses your personal data only in compliance with
data protection laws. For further information on how
Accenture processes your personal data, please see our
privacy statement at
https://www.accenture.com/us-en/privacy-policy.
www.accenture.com <http://www.accenture.com>;
Xymon at xymon.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xymon.com_mailman_listinfo_xymon&d=DwMD-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=S-aLwpx-PHBTBMIG_c2JczRC0SfuZCmsiH9Iams25FI&m=nCeHIt-8vEpIrED5Cu3dEPfxpWypoQE_ddD6QQAX9Ws&s=dlri1VGEnUrfF1SmKT2_B0vclSkFM--ZA8iIjLbfCtk&e=>;