Item "PROCS" not complete
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
The problem occurs today and on "Client data avaliable", i see this on 'ps' section:
[ps] PID PPID USER STARTED S PRI %CPU TIME %MEM RSZ VSZ CMD 1 0 root Oct 03 S 19 0.0 00:00:09 0.0 924 19352 /sbin/init 558 1 root Oct 03 S 23 0.0 00:00:00 0.0 248 10908 /sbin/udevd -d 692 32680 zimbra Mar 30 S 19 0.0 00:00:00 0.0 672 6148 /usr/bin/vmstat -n -S K 30 770 32686 zimbra Mar 30 S 19 0.0 00:00:05 0.0 820 4128 /usr/bin/iostat -d -k 30 794 32708 root Mar 30 S 19 0.0 00:00:00 0.0 2820 90440 sudo /opt/zimbra/libexec/zmstat-fd 800 794 root Mar 30 S 19 0.0 00:00:02 0.0 6896 46416 /usr/bin/perl -w /opt/zimbra/libexec/zmstat-fd 809 32682 zimbra Mar 30 S 19 0.0 00:00:04 0.0 820 4128 /usr/bin/iostat -d -k -x 30 988 558 root Oct 03 S 21 0.0 00:00:00 0.0 232 10904 /sbin/udevd -d 1430 1 root Oct 03 S 19 0.0 02:12:08 0.0 1808 185132 /usr/sbin/vmtoolsd 1547 1 root Oct 03 S 19 0.0 02:59:46 0.0 5800 256212 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5 1595 1 root Oct 03 S 19 0.0 00:01:45 0.0 824 452264 automount --pid-file /var/run/autofs.pid 1616 1 root Oct 03 S 19 0.0 00:00:08 0.0 604 66252 /usr/sbin/sshd 1632 1 ntp Oct 03 S 19 0.0 00:00:14 0.0 976 25936 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g 1687 1 root Oct 03 S 19 0.0 00:03:33 0.0 772 117280 crond 1749 1 root Oct 03 S 19 0.0 00:00:01 0.0 540 100924 rhnsd 1793 1 root Oct 03 S 19 0.0 00:00:00 0.0 452 103888 /usr/bin/rhsmcertd 3181 32618 postfix 11:16:30 S 19 0.0 00:00:00 0.0 5476 98240 smtpd -n [127.0.0.1]:10030 -t inet -u -o local_recipient_maps= -o virtual_mailbox_maps= -o virtual_alias_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_milters=inet:localhost:8465 -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_sender_restrictions= -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_reject_unlisted_sender=no -o smtpd_relay_restrictions= -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= -o syslog_name=postfix/dkimmilter -o content_filter=smtp-amavis:[127.0.0.1]:10032 3634 32618 postfix 19:51:29 S 19 0.0 00:00:30 0.0 6068 54104 qmgr -l -t unix -u 3643 32618 postfix 19:51:32 S 19 0.0 00:00:02 0.0 3192 51320 anvil -l -t unix -u 3649 32618 postfix 19:51:46 S 19 0.0 00:00:01 0.0 3220 51192 tlsmgr -l -t unix -u 3959 11041 root Mar 20 S 19 0.0 00:00:00 0.0 2244 64744 su - root 3964 3959 root Mar 20 S 19 0.0 00:00:00 0.0 2028 108392 -bash 4469 1 root Oct 03 S 19 0.0 00:00:00 0.0 412 4060 /sbin/mingetty /dev/tty1 4499 1 root Oct 03 S 19 0.0 00:00:00 0.0 412 4060 /sbin/mingetty /dev/tty2 4504 1 root Oct 03 S 19 0.0 00:00:00 0.0 412 4060 /sbin/mingetty /dev/tty3 4509 1 root Oct 03 S 19 0.0 00:00:00 0.0 412 4060 /sbin/mingetty /dev/tty4 4515 558 root Oct 03 S 21 0.0 00:00:00 0.0 228 10904 /sbin/udevd -d 4546 1 root Oct 03 S 19 0.0 00:00:00 0.0 412 4060 /sbin/mingetty /dev/tty5 4560 1 root Oct 03 S 19 0.0 00:00:00 0.0 412 4060 /sbin/mingetty /dev/tty6 4889 21073 root Mar 19 S 19 0.0 00:00:00 0.0 1940 161476 su - zimbra 4890 4889 zimbra Mar 19 S 19 0.0 00:00:00 0.0 2180 108524 -bash 5065 32618 postfix 11:18:08 S 19 0.0 00:00:00 0.0 5476 98236 smtpd -n [127.0.0.1]:10030 -t inet -u -o local_recipient_maps= -o virtual_mailbox_maps= -o virtual_alias_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_milters=inet:localhost:8465 -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_sender_restrictions= -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_reject_unlisted_sender=no -o smtpd_relay_restrictions= -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= -o syslog_name=postfix/dkimmilter -o content_filter=smtp-amavis:[127.0.0.1]:10032 5434 32618 postfix 11:18:22 S 19 0.0 00:00:00 0.0 3028 51232 showq -t unix -u 6499 32618 postfix 10:43:29 S 19 0.0 00:00:00 0.0 2940 51096 pickup -l -t unix -u 7137 1 zimbra Dec 13 R 9 99.6 108-12:41:42 0.7 121688 251604 /opt/zimbra/amavisd/sbin/amavisd (ch19-07137-19) 8017 32618 postfix 11:45:18 S 19 0.2 00:00:01 0.0 4476 53408 proxymap -t unix -u 8498 32618 postfix 11:45:26 S 19 0.0 00:00:00 0.0 5372 98240 smtpd -n [127.0.0.1]:10025 -t inet -u -o content_filter= -o local_recipient_maps= -o virtual_mailbox_maps= -o virtual_alias_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= -o smtpd_helo_restrictions= -o smtpd_milters= -o smtpd_sender_restrictions= -o smtpd_reject_unlisted_sender=no -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks_style=host -o mynetworks=127.0.0.0/8,[::1]/128 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings -o local_header_rewrite_clients= -o syslog_name=postfix/amavisd 8805 32618 postfix 11:33:30 S 19 0.0 00:00:00 0.0 5480 98240 smtpd -n [127.0.0.1]:10030 -t inet -u -o local_recipient_maps= -o virtual_mailbox_maps= -o virtual_alias_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_milters=inet:localhost:8465 -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_sender_restrictions= -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_reject_unlisted_sender=no -o smtpd_relay_restrictions= -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= -o syslog_name=postfix/dkimmilter -o content_filter=smtp-amavis:[127.0.0.1]:10032 9630 32618 postfix 11:03:53 S 19 0.0 00:00:00 0.0 5380 98244 smtpd -n [127.0.0.1]:10025 -t inet -u -o content_filter= -o local_recipient_maps= -o virtual_mailbox_maps= -o virtual_alias_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= -o smtpd_helo_restrictions= -o smtpd_milters= -o smtpd_sender_restrictions= -o smtpd_reject_unlisted_sender=no -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks_style=host -o mynetworks=127.0.0.0/8,[::1]/128 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings -o local_header_rewrite_clients= -o syslog_name=postfix/amavisd 10610 32618 postfix 11:46:03 S 19 0.1 00:00:00 0.0 3172 51208 trivial-rewrite -n rewrite -t unix -u 10611 32618 postfix 11:46:03 S 19 0.1 00:00:00 0.0 4476 53424 proxymap -t unix -u 10618 32618 postfix 11:46:03 S 19 0.0 00:00:00 0.0 5980 100340 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11040 29813 root Mar 20 S 19 0.0 00:00:00 0.0 1940 161476 su - zimbra 11041 11040 zimbra Mar 20 S 19 0.0 00:00:00 0.0 2184 108524 -bash 11186 32618 postfix 11:46:19 S 19 0.0 00:00:00 0.0 5376 98240 smtpd -n [127.0.0.1]:10025 -t inet -u -o content_filter= -o local_recipient_maps= -o virtual_mailbox_maps= -o virtual_alias_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= -o smtpd_helo_restrictions= -o smtpd_milters= -o smtpd_sender_restrictions= -o smtpd_reject_unlisted_sender=no -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks_style=host -o mynetworks=127.0.0.0/8,[::1]/128 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings -o local_header_rewrite_clients= -o syslog_name=postfix/amavisd 11495 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 3280 51320 cleanup -z -t unix -u 11496 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11498 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11501 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11502 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 5984 100340 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11503 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 3276 51320 cleanup -z -t unix -u 11504 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11506 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 6164 100336 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11507 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11508 32618 postfix 11:46:33 S 19 0.0 00:00:00 0.0 3268 51316 cleanup -z -t unix -u 11605 32618 postfix 11:47:07 S 19 0.2 00:00:00 0.0 4480 53408 proxymap -t unix -u 11606 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11608 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11609 32618 postfix 11:47:07 S 19 0.2 00:00:00 0.0 4480 53416 proxymap -t unix -u 11611 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11612 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11613 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 5976 100336 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11614 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11615 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11617 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11618 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11620 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11622 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11623 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11626 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3276 51320 cleanup -z -t unix -u 11632 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11634 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11635 32618 postfix 11:47:07 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11639 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51320 cleanup -z -t unix -u 11640 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 5960 100332 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11642 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11643 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11645 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11647 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51320 cleanup -z -t unix -u 11650 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11652 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11657 32618 postfix 11:47:08 S 19 0.2 00:00:00 0.0 4512 53416 proxymap -t unix -u 11665 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11667 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11669 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11671 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11673 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11676 32618 postfix 11:47:08 S 19 0.1 00:00:00 0.0 3116 51216 trivial-rewrite -n rewrite -t unix -u 11678 32618 postfix 11:47:08 S 19 0.2 00:00:00 0.0 4548 53540 proxymap -t unix -u 11680 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11683 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 5952 100336 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11687 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11690 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11692 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3268 51316 cleanup -z -t unix -u 11693 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11694 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11695 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 5972 100336 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11696 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11697 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11701 32618 postfix 11:47:08 S 19 0.0 00:00:00 0.0 5956 100336 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11707 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 6176 100336 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11709 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 5964 100332 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11712 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 6140 100332 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11714 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11715 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11716 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 3276 51320 cleanup -z -
2014-03-28 1:01 GMT-03:00 Jeremy Laidman <jlaidman at rebel-it.com.au>:
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
On 2 April 2014 06:58, Sidiney M. Crescencio Junior <sidiney at redix.com.br>wrote:
11712 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 6140 100332 smtpd -n smtp -t inet -u -o stress= -o content_filter=scan:[127.0.0.1]:10030 11714 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 3276 51316 cleanup -z -t unix -u 11715 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 3272 51316 cleanup -z -t unix -u 11716 32618 postfix 11:47:09 S 19 0.0 00:00:00 0.0 3276 51320 cleanup -z -
The last line here looks to have been truncated, as Henrik predicted. So you need to increase MAXMSG_CLIENT. Either your change hasn't been activated, or it needs to be increased even further.
Go to the "xymond" page for the Xymon server itself. Near the end but before the graph, you can probably see something like:
Oversize status msg from 10.1.1.99 for hostname.example.org:procs truncated (n=1262366, limit=1048576)
The second value (limit) represents the limit configured in MAXMSG_CLIENT, but is multiplied by 1024. So if you set MAXMSG_CLIENT to 1536, this would probably show as "limit=1572864". If the first value is greater than the second, you need to increase MAXMSG_CLIENT.
Cheers Jeremy
participants (4)
-
henrik＠hswn.dk
-
jlaidman＠rebel-it.com.au
-
sidiney＠redix.com.br
-
SKreien＠la-z-boy.com