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>; Xymon MailingList
<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=>;