I have a problem and i'm unable to resolve . Under " PROCS " , sometimes the Xymon just not sending the message completely , as follows:
Problem situation :
Accuse as if they were not running , and the list of processes does not come entirely.
Wed Mar 12 09:46:48 EDT 2014 - Processes NOT ok
green udevd (found 3 , req . 1 or more) green sshd (found 1 , req . 1 or more) green master ( found 1 , req . 1 or more) green crond (found 1 , req . 1 or more) red clamd (found 0 , req . 1 or more) green amavisd (found 3 , req . 1 or more) red xinetd (found 0 , req . 1 or more) red slapd (found 0 , req . 1 or more) green rsyslogd (found 1 , req . 1 or more) green ntpd (found 1 , req . 1 or more)
USER PID PPID PRI STARTED S % CPU % MEM TIME RSZ VSZ CMD Oct 03 1 0 root S 19 0.0 00:00:07 0.0 1396 19352 / sbin / init Postfix 08:34:26 453 21763 S 19 0.0 00:00:00 0.0 5376 98228 smtpd -n [ 127.0.0.1 ] : 10025 - t inet - u-o content_filter = -o = -o local_recipient_maps virtual_mailbox_maps = virtual_alias_maps = -o it relay_recipient_maps smtpd_restriction_classes = it = it = in - the smtpd_delay_reject smtpd_client_restrictions = permit_mynetworks , reject it smtpd_data_restrictions smtpd_end_of_data_restrictions = it = it = it smtpd_helo_restrictions smtpd_milters smtpd_sender_restrictions = it = it = in - the smtpd_reject_unlisted_sender smtpd_relay_restrictions = - the smtpd_recipient_restrictions = permit_mynetworks , reject- the mynetworks_style = host mynetworks = 127.0.0.0 -o / 8 , [ :: 1 ] / 128 = yes it strict_rfc821_envelopes it smtpd_error_sleep_time = 0 it smtpd_soft_error_limit = 1001 = 1000 it smtpd_hard_error_limit it smtpd_client_connection_count_limit = 0 = 0 it smtpd_client_connection_rate_limit it receive_override_options = no_header_body_checks , no_unknown_recipient_checks , no_address_mappings it local_header_rewrite_clients = it = syslog_name postfix / amavisd Postfix 09:39:49 553 21763 S 19 0.0 00:00:00 0.0 3300 51276 smtp- t unix
- u Oct 03 558 1 root S 23 0.0 00:00:00 0.0 316 10908 / sbin / udevd - d Oct 03 988 558 root S 21 0.0 00:00:00 0.0 336 10904 / sbin / udevd - d 03 Oct 1430 1 root S 19 0.0 0.0 3344 185132 01:57:04 / usr / sbin / vmtoolsd 03 Oct 1547 1 root S 19 0.0 02:30:58 0.0 6068 256212 / sbin / rsyslogd -i / var / run / c - syslogd.pid 5 03 Oct 1595 1 root S 19 0.0 00:01:35 0.0 1288 452264 automount - pid - file / var / run / autofs.pid 03 Oct 1616 1 root S 19 0.0 00:00:07 0.0 616 66252 / usr / sbin / sshd Ntp 03 Oct 1632 1 S 19 0.0 00:00:12 0.0 1132 25936 ntpd - u ntp : ntp - p / var / run / ntpd.pid - g 03 Oct 1687 1 root S 19 0.0 00:03:08 0.0 784 117280 crond Postfix 09:07:23 1731 21763 S 19 0.0 00:00:00 0.0 6240 100456 465 smtpd -n
- t inet - u - stress = -o content_filter = scan : [ 127.0.0.1 ] : 10030 -o = yes smtpd_tls_wrappermode it smtpd_sasl_auth_enable = yes it smtpd_client_restrictions = it = smtpd_data_restrictions it smtpd_helo_restrictions = it = smtpd_recipient_restrictions = permit_sasl_authenticated smtpd_relay_restrictions it , reject it syslog_name = postfix / smtps it milter_macro_daemon_name = ORIGINATING 03 Oct 1749 1 root S 19 0.0 00:00:01 0.0 544 100924 rhnsd Zimbra Mar 1761 30637 07 S 19 0.1 00:07:51 0.1 26904 784316 / opt / zimbra / opendkim / sbin / opendkim -x / opt / zimbra / conf / opendkim.conf - u zimbra 03 Oct 1793 1 root S 19 0.0 0.0 492 103888 00:00:00 / usr / bin / rhsmcertd Zimbra Mar 1 3534 10 S 19 0.0 00:00:19 0.6 100476 217852 / opt / zimbra / amavisd / sbin / amavisd ( master) 03 Oct 4469 1 root S 19 0.0 00:00:00 0.0 464 4060 / sbin / mingetty / dev/tty1 03 Oct 4499 1 root S 19 0.0 00:00:00 0.0 464 4060 / sbin / mingetty / dev/tty2 03 Oct 4504 1 root S 19 0.0 00:00:00 0.0 464 4060 / sbin / mingetty / dev/tty3 03 Oct 4509 1 root S 19 0.0 00:00:00 0.0 464 4060 / sbin / mingetty / dev/tty4 Oct 03 4515 558 root S 21 0.0 00:00:00 0.0 328 10904 / sbin / udevd - d 03 Oct 4546 1 root S 19 0.0 00:00:00 0.0 464 4060 / sbin / mingetty / dev/tty5 03 Oct 4560 1 root S 19 0.0 00:00:00 0.0 464 4060 / sbin / mingetty / dev/tty6
Has anyone experienced this and know how to treat?
Den 2014-03-13 19:28, Sidiney M. Crescencio Junior skrev:
I have a problem and i'm unable to resolve . Under " PROCS " , sometimes the Xymon just not sending the message completely , as follows:
It has been reported before, and is usually caused by the client data containing a very long list of network connections. Have a look at the "client data" when you have this situation (you can see it in the history logs), and you will probably find that the client data has been truncated somewhere in the middle of the '[ps]' section.
The problem is that the output from netstat precedes the ps-listing in the client data, so if you have a lot of network connections listed, the client message becomes too large, and is truncated.
Try increasing the max size of the client message data by setting MAXMSG_CLIENT in xymonserver.cfg. You need to restart the Xymon server when changing this.
Regards, Henrik
MAXMSG_CLIENT= 1536 now and the problem occur again tonight, but i only reloaded the xymon, now i restarted the xymon server.
2014-03-14 7:42 GMT-03:00 Henrik Størner <henrik at hswn.dk>:
Den 2014-03-13 19:28, Sidiney M. Crescencio Junior skrev:
I have a problem and i'm unable to resolve . Under " PROCS " , sometimes the Xymon just not sending the message completely , as follows:
It has been reported before, and is usually caused by the client data containing a very long list of network connections. Have a look at the "client data" when you have this situation (you can see it in the history logs), and you will probably find that the client data has been truncated somewhere in the middle of the '[ps]' section.
The problem is that the output from netstat precedes the ps-listing in the client data, so if you have a lot of network connections listed, the client message becomes too large, and is truncated.
Try increasing the max size of the client message data by setting MAXMSG_CLIENT in xymonserver.cfg. You need to restart the Xymon server when changing this.
Regards, Henrik
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 14 March 2014 21:42, Henrik Størner <henrik at hswn.dk> wrote:
It has been reported before, and is usually caused by the client data containing a very long list of network connections.
Would it be possible to have xymond recognise a client data message that is compressed and auto-decompress it? Then we could insert a "| gzip" into xymonclient.sh, and many of these problems would go away.
In fact, having a generic pre-processor plug-in framework could be really useful beyond just compression. It could perform authentication to compare status/data message signatures against public keys (or certs) stored in a xymon-hostkeys.cfg file, and reject messages that don't match the signing key for a host. A plug-in for encryption would work the same way.
Or is this something that could be achieved by writing a custom channel handler? I should be able to write a generic decompressor and then instantiate it by adjusting tasks.cfg to run:
xymond_channel --channel=client --log=/var/log/xymon/clientdata.log xymond_gunzip --log=/var/log/xymon/gunzip.log xymond_client
J
Den 2014-03-17 13:17, Jeremy Laidman skrev:
On 14 March 2014 21:42, Henrik Størner <henrik at hswn.dk [1]> wrote:
It has been reported before, and is usually caused by the client data containing a very long list of network connections.
Would it be possible to have xymond recognise a client data message that is compressed and auto-decompress it? Then we could insert a "| gzip" into xymonclient.sh, and many of these problems would go away.
In fact, having a generic pre-processor plug-in framework could be really useful beyond just compression. It could perform authentication to compare status/data message signatures against public keys (or certs) stored in a xymon-hostkeys.cfg file, and reject messages that don't match the signing key for a host. A plug-in for encryption would work the same way.
Much of this has already been put into version 5: Compression, TLS encryption and client authentication via client SSL certificates. So it is pretty much done.
Regards, Henrik
Links:
[1] mailto:henrik at hswn.dk
Has BBWin been tested to see if it still works with version 5? That would be painful for many of us. Or better yet, is anyone building a new windows client?
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner Sent: Monday, March 17, 2014 8:23 AM To: xymon at xymon.com Subject: Re: [Xymon] Item "PROCS" not complete
Den 2014-03-17 13:17, Jeremy Laidman skrev: On 14 March 2014 21:42, Henrik Størner <henrik at hswn.dk<mailto:henrik at hswn.dk>> wrote: It has been reported before, and is usually caused by the client data containing a very long list of network connections.
Would it be possible to have xymond recognise a client data message that is compressed and auto-decompress it? Then we could insert a "| gzip" into xymonclient.sh, and many of these problems would go away.
In fact, having a generic pre-processor plug-in framework could be really useful beyond just compression. It could perform authentication to compare status/data message signatures against public keys (or certs) stored in a xymon-hostkeys.cfg file, and reject messages that don't match the signing key for a host. A plug-in for encryption would work the same way.
Much of this has already been put into version 5: Compression, TLS encryption and client authentication via client SSL certificates. So it is pretty much done.
Regards, Henrik
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
On 14 March 2014 21:42, Henrik Størner <henrik at hswn.dk <mailto:henrik at hswn.dk>> wrote:
Much of this has already been put into version 5: Compression, TLS encryption and client authentication via client SSL certificates. So it is pretty much done.
Den 17-03-2014 15:34, Scot Kreienkamp skrev:
Has BBWin been tested to see if it still works with version 5? That would be painful for many of us. Or better yet, is anyone building a new windows client?
Don't worry - I wouldn't dare to release a Xymon server that old clients could not talk to. So all of your existing clients will continue to work, including BBWin.
Having said that, I am also very much aware that BBWin is no longer being maintained. The only Windows client that is being maintained now is the Powershell based client.
Regards, Henrik
On 17 March 2014 23:23, Henrik Størner <henrik at hswn.dk> wrote:
Much of this has already been put into version 5: Compression, TLS encryption and client authentication via client SSL certificates. So it is pretty much done.
That is great news. You've been very busy. Much appreciated.
J
Hello,
The problem still persists, after the parameters commented above, sugestions?
Thanks
2014-03-17 23:06 GMT-03:00 Jeremy Laidman <jlaidman at rebel-it.com.au>:
On 17 March 2014 23:23, Henrik Størner <henrik at hswn.dk> wrote:
Much of this has already been put into version 5: Compression, TLS encryption and client authentication via client SSL certificates. So it is pretty much done.
That is great news. You've been very busy. Much appreciated.
J
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Den 2014-03-26 21:01, Sidiney M. Crescencio Junior skrev:
The problem still persists, after the parameters commented above, sugestions?
Please check:
Do you have any log entries on the Xymon server in xymond.log about messages that are too large?
If you click on the "client data" link in the procs status, does it show the entire "ps"listing in the '[ps]' section?
Regards, Henrik
No entries in xymond.log, only in notifications.log
Wed Mar 26 08:36:42 2014 assopo.xxx.com.br.procs (0.0.0.0) sentinela at xxx.com.br 1395833802 300 Wed Mar 26 08:36:46 2014 assopo.xxx.com.br.procs (0.0.0.0) REPEAT=2h 1395833802 300
I don't understand, how/where is the client data?
2014-03-27 6:18 GMT-03:00 Henrik Størner <henrik at hswn.dk>:
Den 2014-03-26 21:01, Sidiney M. Crescencio Junior skrev:
The problem still persists, after the parameters commented above, sugestions?
Please check:
Do you have any log entries on the Xymon server in xymond.log about messages that are too large?
If you click on the "client data" link in the procs status, does it show the entire "ps"listing in the '[ps]' section?
Regards, Henrik
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 28 March 2014 04:55, Sidiney M. Crescencio Junior <sidiney at redix.com.br>wrote:
I don't understand, how/where is the client data?
Go to the "procs" page for the server having the problem. At the bottom of the page you should see the line "Client data available". Click on the words "client data" which should be a link that takes you to the client data.
J
participants (4)
-
henrik＠hswn.dk
-
jlaidman＠rebel-it.com.au
-
sidiney＠redix.com.br
-
SKreien＠la-z-boy.com