Postfix sendmail returning status code 75

RT Users
1

I’m having a devil of a time with this. We’re running RT 4.0.13 on
SUSE Linux Enterprise Server 11 SP2. The MTA is Postfix.

Seemingly for no reason, outgoing emails from RT start failing.
Cleaning the Mason cache and restarting Apache2 seems to solve the
problem temporarily (some hours, but by the next morning at the latest
the problem returns).

Each time it drops an email in this way, RT writes the following two
log messages:

RT: rt-4.0.13-7424-1375250475-1273.35071-4-0@suse.de:
/usr/sbin/sendmail -oi -t exited with code 75
(/usr/lib/perl5/vendor_perl/5.10.0/RT/Interface/Email.pm:486)

RT: rt-4.0.13-7424-1375250475-1273.35071-4-0@suse.de: Could not send
mail with command /usr/sbin/sendmail -oi -t:
rt-4.0.13-7424-1375250475-1273.35071-4-0@suse.de:
/usr/sbin/sendmail -oi -t exited with code 75 at /usr/lib
/perl5/vendor_perl/5.10.0/RT/Interface/Email.pm line 487. Stack:
[/usr/lib/perl5/vendor_perl/5.10.0/RT/Interface/Email.pm:48
7] [/usr/lib/perl5/vendor_perl/5.10.0/RT/Action/SendEmail.pm:292]
[/usr/lib/perl5/vendor_perl/5.10.0/RT/Action/SendEmail.pm
:114] [/usr/lib/perl5/vendor_perl/5.10.0/RT/ScripAction.pm:232]
[/usr/lib/perl5/vendor_perl/5.10.0/RT/Scrip.pm:475] [/usr
/lib/perl5/vendor_perl/5.10.0/RT/Scrips.pm:188]
[/usr/lib/perl5/vendor_perl/5.10.0/RT/Transaction.pm:201]
[/usr/lib/perl5/v
endor_perl/5.10.0/RT/Record.pm:1504]
[/usr/lib/perl5/vendor_perl/5.10.0/RT/Ticket.pm:682]
[/usr/lib/perl5/vendor_perl/5.10.
0/RT/Interface/Email.pm:1569]
[/usr/share/request-tracker/html/REST/1.0/NoAuth/mail-gateway:61]
(/usr/lib/perl5/vendor_perl/5
.10.0/RT/Interface/Email.pm:491)

I have the following options in RT_SiteConfig.pm:

Set($MailCommand, “sendmailpipe”);
Set($SendmailArguments, ‘-oi -t’);

I read this thread where someone had a very similar problem:

http://requesttracker.8502.n7.nabble.com/sendmail-error-exited-with-code-75-RHEL6-td7144.html

In their case, adding “PerlOptions +Parent” to their vhost
configuration file solved the problem, but I did that and it doesn’t
help in my case.

If I don’t restart Apache, the problem seems to get worse over time.

I have prepared a wrapper for sendmail that will log the exact
messages that are causing this to happen, but I haven’t deployed it
yet. (Still testing it.)

Since status code 75 is only a temporary error whereby Postfix is
(apparently) just saying that it is queuing the message to send later,
I’m wondering if I could just patch RT to ignore status code 75 and
treat it the same as success?

Any other ideas?

Nathan

2

I’m having a devil of a time with this. We’re running RT 4.0.13 on
SUSE Linux Enterprise Server 11 SP2. The MTA is Postfix.

Seemingly for no reason, outgoing emails from RT start failing.
Cleaning the Mason cache and restarting Apache2 seems to solve the
problem temporarily (some hours, but by the next morning at the latest
the problem returns).

What kind of monitoring do you have on the box? Often, this is a
memory problem (the running out kind).

Each time it drops an email in this way, RT writes the following two
log messages:

RT: rt-4.0.13-7424-1375250475-1273.35071-4-0@suse.de:
/usr/sbin/sendmail -oi -t exited with code 75
(/usr/lib/perl5/vendor_perl/5.10.0/RT/Interface/Email.pm:486)

I read this thread where someone had a very similar problem:

http://requesttracker.8502.n7.nabble.com/sendmail-error-exited-with-code-75-RHEL6-td7144.html

In their case, adding “PerlOptions +Parent” to their vhost
configuration file solved the problem, but I did that and it doesn’t
help in my case.

PerlOptions +Parent was required because they ran two perl processes
in a single mod_perl host. Are you doing that?

If I don’t restart Apache, the problem seems to get worse over time.

I have prepared a wrapper for sendmail that will log the exact
messages that are causing this to happen, but I haven’t deployed it
yet. (Still testing it.)

Since status code 75 is only a temporary error whereby Postfix is
(apparently) just saying that it is queuing the message to send later,
I’m wondering if I could just patch RT to ignore status code 75 and
treat it the same as success?

What’s in your postfix error logs when this happens?

-kevin

3

Thanks for your reply, Kevin, and here are my answers to your questions.

What kind of monitoring do you have on the box? Often, this is a
memory problem (the running out kind).

We are monitoring the box with Icinga. I will talk with my colleagues
to see if we can tweak the Icinga configuration so it complains
earlier when memory starts to get low. The box has 8Gb installed, but
it runs more stuff than just RT.

PerlOptions +Parent was required because they ran two perl processes
in a single mod_perl host. Are you doing that?

Well, I’m certainly not. And it didn’t make the problem go away, so I
assume this is a dead end and I will remove that option.

What’s in your postfix error logs when this happens?

postfix/sendmail[26576]: fatal: wwwrun(30): No recipient addresses
found in message header

My “sendmail wrapper” is now in place and I will be watching closely
tomorrow. Today from what I managed to capture it looked like nothing
(or only one byte?) was being piped from RT to “sendmailpipe”. This is
consistent with what was written to the log (No recipient addresses
found).

Thanks!

4

postfix/sendmail[26576]: fatal: wwwrun(30): No recipient addresses
found in message header

My “sendmail wrapper” is now in place and I will be watching closely
tomorrow. Today from what I managed to capture it looked like nothing
(or only one byte?) was being piped from RT to “sendmailpipe”. This is
consistent with what was written to the log (No recipient addresses
found).

My guess is that you’re running RT 4 under mod_perl with the wrong
SetHandler value. Read
Web deployment - RT 5.0.5 Documentation - Best Practical and
compare your config.

5

My guess is that you’re running RT 4 under mod_perl with the wrong
SetHandler value. Read
Web deployment - RT 5.0.5 Documentation - Best Practical and
compare your config.

No, mine seems to check out. Here it is:

AddDefaultCharset UTF-8

PerlSetEnv RT_SITE_CONFIG /etc/request-tracker/RT_SiteConfig.pm

You might need to alter references to /rt in this file (there are

three) to match whatever base URL you are using for your RT site

Alias / /usr/share/request-tracker/html

SetHandler modperl PerlResponseHandler Plack::Handler::Apache2 PerlSetVar psgi_app /usr/sbin/rt-server # Options None # Order allow,deny # Allow from all

Limit mail gateway access to localhost by default

<Location /REST/1.0/NoAuth>
Order Allow,Deny
Allow from 127.0.0.1

use Plack::Handler::Apache2; Plack::Handler::Apache2->preload("/usr/sbin/rt-server");

Today I have been keeping a close watch on the server’s memory. So far
I haven’t seen any less than 80% free, and no error so far, either.

Nathan