Truncated email alerts 🔗 link

     All, has anyone seen an issue where email messages that Xymon
generates (NOTE: not the client status on the webpage, which is
complete) are getting truncated beyond a certain length?  We had already
bumped up MAXMSG_STATUS and MAXMSG_CLIENT for a different issue (where
the status messages going to the server were getting truncated), but
this is different.  For example, an alarm gets generated, and on the
xymon webpage, you can see the entire status.  The email we receive,
however, is truncated.  We're running Xymon 4.2.3 on RHEL5.  We're
trying to track down what layer this at, and it's proving a challenge.
We're seeing this across different alarms, but they all seem to get
truncated around 6kb.

Regards,

Mark

What does your alert config look like?

On Aug 23, 2010 7:47 PM, "Mark Stoltzfus" <user-5b4ba45c8394@xymon.invalid>

wrote:

      All, has anyone seen an issue where email messages that Xymon
generates (NOTE: not the client status on the webpage, which is complete) are
getting truncated beyond a certain length?  We had already bumped up
MAXMSG_STATUS
and MAXMSG_CLIENT for a different issue (where the status messages going to
the server were getting truncated), but this is different.  For example, an
alarm gets generated, and on the xymon webpage, you can see the entire
status.  The email we receive, however, is truncated.  We’re running Xymon
4.2.3 on RHEL5.  We’re trying to track down what layer this at, and it’s
proving a challenge.  We’re seeing this across different alarms, but they
all seem to get truncated around 6kb.

Regards,

Mark

We use a mix of alert scripts with a mix of instructions for different
recipients, some written in PHP, some in bourne shell, that all show the
same behavior.  The hobbit-alerts.cfg is rather large (400+ lines), but
a typical line looks like this:

 
PAGE=production

SCRIPT /opt/xymon/scripts/notify_unix.sh user-5b4ba45c8394@xymon.invalid
DURATION>2m EXSERVICE=$NOC_IGNORE REPEAT=9999

 
Where NOC_IGNORE is set to services our NOC folks don't care about.
Maybe a better question would be, does anyone get email alerts that are
larger than 6kb?

 
Regards,

 
Mark

 
From: Josh Luthman [mailto:user-4c45a83f15cb@xymon.invalid] 
Sent: Monday, August 23, 2010 4:52 PM
To: xymon at xymon.com
Subject: Re: [xymon] Truncated email alerts

 
What does your alert config look like?

	On Aug 23, 2010 7:47 PM, "Mark Stoltzfus"
<user-5b4ba45c8394@xymon.invalid> wrote:

	     All, has anyone seen an issue where email messages that
Xymon generates (NOTE: not the client status on the webpage, which is
complete) are getting truncated beyond a certain length?  We had already
bumped up MAXMSG_STATUS and MAXMSG_CLIENT for a different issue (where
the status messages going to the server were getting truncated), but
this is different.  For example, an alarm gets generated, and on the
xymon webpage, you can see the entire status.  The email we receive,
however, is truncated.  We're running Xymon 4.2.3 on RHEL5.  We're
trying to track down what layer this at, and it's proving a challenge.
We're seeing this across different alarms, but they all seem to get
truncated around 6kb.

	Regards,

	Mark

Hi

We're formatting a few status messages as HTML and we are using the perl HTML script from Andy France/Martin Ward/David Baldwin.
Our mails kept getting truncated at around 4000 characters.

After looking around in the source code (do_alert.c) I found out that the variable passed to the SCRIPT alert type is limited to 4096 characters.
I increased the value to 12288 and recompiled the xymond_alert binary. After replacing it in our production system the script now receives the complete status message.

Why can we configure the MAXMSG size for status messages but is the status truncated to 4KB?
I'm wondering if there's any harm in upping the MAX_ALERTMSG_SCRIPTS value. Memory? Stabililty?

Thanks

MEDIALAAN Disclaimer<http://medialaan.be/email>;

On Fri, January 16, 2015 9:06 am, Bert Willekens wrote:

Since the data's being passed via environment variable, a safety limit is
definitely a good idea, but modern systems should be able to exceed 4k
easily enough, so I don't think you'd see any negative effects going up a
bit higher.

I'd agree, it'd be preferable to set this via environment variable. Even
better would be a SCRIPT-like directive that takes the status/page message
body via STDIN instead.


Regards,

-jc