RT starts munging attachments again

mYK · September 26, 2003, 4:34pm

Hi all,

Thanks to all the help on the list, RT is handling binary attachments
properly with the LANG=en_US fix.

However, ever since the fix was made, RT reverts to the old munging
behavior some time during the night and it’s broken again in the
morning. All i have to do is

/var/www/bin/apachectl stop
/var/www/bin/apachectl start

as root with LANG=en_US, which makes it work again, but obviously this
is not a very good solution.

my /etc/sysconfig/i18n has LANG=en_US.

Does apache do something at night to reset itself? And if so, where
does it pull its environment? Should i recompile it?

Thanks,
mike

Jesse_Vincent · September 26, 2003, 10:36pm

Hi all,

Thanks to all the help on the list, RT is handling binary attachments
properly with the LANG=en_US fix.

However, ever since the fix was made, RT reverts to the old munging
behavior some time during the night and it’s broken again in the
morning. All i have to do is

/var/www/bin/apachectl stop
/var/www/bin/apachectl start

as root with LANG=en_US, which makes it work again, but obviously this
is not a very good solution.

my /etc/sysconfig/i18n has LANG=en_US.

Does apache do something at night to reset itself? And if so, where
does it pull its environment? Should i recompile it?

You might want to restart cron.

Thanks,
mike

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Robert_Spier · September 29, 2003, 1:13am

my /etc/sysconfig/i18n has LANG=en_US.

Does apache do something at night to reset itself? And if so, where
does it pull its environment? Should i recompile it?

You might want to restart cron.

Or even use the big hammer and reboot the whole machine. Apache
shouldn’t be stopping and restarting at night, although it depends on
your particular setup. And there would be evidence in the logs.

By restarting the machine, you’ll clear out any old instances where LANG
is set to a UTF8 mode.

-R

mYK · September 30, 2003, 5:09pm

The solution to this was to install Perl 5.8.1-rc-whatever from Redhat
Rawhide, and recompile mod_perl and apache against that. (plus i had to
CPAN some overwritten modules)

There’s a discussion here:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87682

Mike White wrote:

mYK · September 30, 2003, 8:01pm

Looks like i jumped the gun here. Since i implemented this fix late
last night, it took until today around 11 or noon for attachments to
start being corrupted again.

Maybe i’ll play around with Apache’s MaxRequestsPerChild…?

Maybe i’ll try completely recompiling Perl from scratch.

Any other ideas?

Thanks,
mike

Mike White wrote:

mYK · October 8, 2003, 6:36pm

Hi all,

RT 3.0.5 / Redhat 9 / Apache 1.3.28 (w/static mod_perl) / Perl 5.8.1.

The temporary fix to my “attachment munging” issue (sometimes
attachments are corrupted and sometimes they’re fine) was to set cron to
restart apache every 15 minutes. This seems to work most of the time,
but it still seems to get into a bad state occasionally. (usually when
it’s been used heavily for the 13-14 minutes before a reset)

Here is some more interesting information.

The headers from a comment where the attachment (test.doc) has been
corrupted:

Wed Oct 01 16:30:01 2003 mwhite - Comments added [Reply] [Comment]

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=“----------=_1065051001-14283-7”
X-Mailer: MIME-tools 5.411 (Entity 5.404)
X-RT-Original-Encoding: utf-8
RT-Send-CC:
RT-Send-BCC:
Content-Length: 0

MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
Content-Type: multipart/mixed; boundary=“----------=_1065051001-14283-6”
Content-Length: 0

Content-Type: application/msword; name=“test.doc”
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename=“test.doc”
Content-Length: 21101

Download test.doc 20.6k

The headers from an attachment after apache has been restarted:

Wed Oct 01 16:30:18 2003 mwhite - Comments added [Reply]

[Comment]

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=“----------=_1065051018-15258-1”
X-Mailer: MIME-tools 5.411 (Entity 5.404)
X-RT-Original-Encoding: ascii
RT-Send-CC:
RT-Send-BCC:
Content-Length: 0

Content-Type: text/plain; charset=“utf-8”
Content-Transfer-Encoding: binary
Content-Disposition: inline
X-RT-Original-Encoding: utf-8
Content-Length: 91

[mwhite - Wed Oct 01 16:30:01 2003]:

This transaction appears to have no content

Download (untitled) 91b

MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
Content-Type: multipart/mixed; boundary=“----------=_1065051018-15258-0”
Content-Length: 0

Content-Type: application/msword; name=“test.doc”
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename=“test.doc”
Content-Length: 19456

Download test.doc 19k

The second test.doc works fine. (and is the correct size, 19k)

Note that X-RT-Original-Encoding: of the first message is ascii, and the
second is UTF-8. Both were made as comments in the web interface.

Any ideas?

Mike

Danie_Marais · October 16, 2003, 10:41am

Mike,

Did you manage to get this sorted out by any chance? I sit with EXACTLY
the same behaviour here. Have tried similar solutions but no go.

Any help would be appreciated.

Thanks!
Danie

mYK · October 16, 2003, 4:39pm

Hi Danie,

I have a cron job that runs as root and does a apachectl restart every
10 minutes. I tried restarting it every 15 minutes, but under high RT
load, the attachments start getting munged towards the end of the 15
minute mark. So, a sub-optimal workaround at best.

Are you running RH9?

Danie Marais wrote:

Vivek_Khera · October 16, 2003, 5:44pm

“MW” == Mike White myk_lists@yahoo.ca writes:

MW> Hi Danie,

MW> I have a cron job that runs as root and does a apachectl restart every
MW> 10 minutes. I tried restarting it every 15 minutes, but under high RT
MW> load, the attachments start getting munged towards the end of the 15
MW> minute mark. So, a sub-optimal workaround at best.

Just curious… between those 10 minutes, do any of your httpd’s
retire due to handling enough requests? What if you reduce max
requests per child down to something like 50?

mYK · October 16, 2003, 6:13pm

MW> I have a cron job that runs as root and does a apachectl restart every
MW> 10 minutes. I tried restarting it every 15 minutes, but under high RT
MW> load, the attachments start getting munged towards the end of the 15
MW> minute mark. So, a sub-optimal workaround at best.

Just curious… between those 10 minutes, do any of your httpd’s
retire due to handling enough requests? What if you reduce max
requests per child down to something like 50?

I did try reducing apache max requests significantly, but it did not help.

wdanielevans · October 16, 2003, 8:07pm

Mike,

I’m having the same problem and curious about the behaviors your seeing,
whether they are similar to mine. I’ve tried both mod_perl and fastcgi
configurations, and the resulting Bad attachment is the same size, but the
behavior is different.

Let me describe the two environments:

FastCGI:

Create a ticket with attachment (non-text GIF, PDF, zip, or Word DOC)
a) first attachment is okay.
b) 2nd attachment is larger in size and corrupt
c) all attachments thereafter are larger in size and corrupt
Re-boot Apache
Repeat behavior in step 1
NOTE: a refresh of the web client creates a New transaction with a GOOD
attachment, even after the 2nd bad attachment, but repeating the refresh
creates additional Bad attachments.

Since this can be replicated, over and over again, and it happens
immediately after the previous ticket created, the 10 minute reboot wouldn’t
help me.

Mod_Perl:

Create a ticket with attachment (non-text GIF, PDF, zip, or Word DOC)
a) first attachment is okay.
b) 2nd attachment is larger in size and corrupt
c) 3rd attachment is Good.
d) next 3 attachments are also Good.
Re-boot not required for 3rd Good and thereafter.
Inconsistent munging, so can’t repeat.

In both configurations, the attachment size of the corrupted version is
exactly the same and consistently the same. For example, a GIF file that has
a size of 116.7k in a Good attachment, will always have a size of 170.3k in
the Bad attachment. And, a PDF with a size of 617k in a Good attachment
will always have a size of 726.7k in the Bad attachment.

I’m running RT 3.02, Apache 1.3.27, MySQL 4.0.13, Perl 5.8.0, and with
mod_perl 1.27 and FastCGI 0.67.

Are you seeing similar behavior?

Thanks,
Dan-----Original Message-----
From: rt-users-admin@lists.fsck.com [mailto:rt-users-admin@lists.fsck.com]
On Behalf Of Mike White Sent: Thursday, October 16, 2003 9:40 AM To: Danie Marais Cc: rt-users@lists.fsck.com Subject: Re: [rt-users] RT starts munging attachments again Hi Danie, I have a cron job that runs as root and does a apachectl restart every 10 minutes. I tried restarting it every 15 minutes, but under high RT load, the attachments start getting munged towards the end of the 15 minute mark. So, a sub-optimal workaround at best. Are you running RH9? Danie Marais wrote:

Mike,

Did you manage to get this sorted out by any chance? I sit with EXACTLY
the same behaviour here. Have tried similar solutions but no go.

rt-users mailing list
rt-users@lists.fsck.com http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

mYK · October 16, 2003, 8:13pm

Dan,

Dan Evans wrote:

In both configurations, the attachment size of the corrupted version is
exactly the same and consistently the same. For example, a GIF file that has
a size of 116.7k in a Good attachment, will always have a size of 170.3k in
the Bad attachment. And, a PDF with a size of 617k in a Good attachment
will always have a size of 726.7k in the Bad attachment.

I’m running RT 3.02, Apache 1.3.27, MySQL 4.0.13, Perl 5.8.0, and with
mod_perl 1.27 and FastCGI 0.67.

Are you seeing similar behavior?

Yes, the corrupted attachments are always corrupted in the same way (ie
an 18k word document becomes 20k and unreadable).

You might want to try RT 3.0.6 (though i’m running 3.0.5, and the
behaviour is the same) and Perl 5.8.1, which handles Redhat’s UTF-8
stuff “better”.

Danie_Marais · October 17, 2003, 10:42am

Mike,

I use RH9 indeed.

Danie_Marais · October 17, 2003, 10:46am

I use RT3.0.6 and Perl 5.8.1. Same problem.

Danie