amavisd: lost connection ... while sending end of data

H

hansaplast

Hi,

I'm having trouble with amavisd-new-2.6.4_2,1 or perl-5.10.1.

After a portupgrade I get the following message in /var/log/messages
Code: 
Sep 15 21:57:15 dn kernel: pid 10738 (perl), uid 110: exited on signal 11
uid 110 = vscan so I suspect amavisd-new or clamav
The maillog shows it's amavisd-new
Code: 
Sep 15 21:57:15 dn postfix/qmgr[4141]: C461717F7D: from=<mythtv-users-
bounces@mythtv.org>, size=4009, nrcpt=1 (queue active)
Sep 15 21:57:15 dn postfix/smtp[11142]: C461717F7D: to=<dump@fqdn.dom>, 
orig_to=<mythtv@fqdn.dom>, relay=127.0.0.1[127.0.0.1]:10024,
delay=5382, delays=5381/0/0/0.14, dsn=4.4.2, status=deferred (lost connection with 
127.0.0.1[127.0.0.1] while sending end of data -- message may be sent more than once)

postqueue -p
Code: 
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C461717F7D     4009 Tue Sep 15 20:27:33  mythtv-users-bounces@mythtv.org
(lost connection with 127.0.0.1[127.0.0.1] while sending end of data -- 
message may be sent more than once)
              dump@fqdn.dom

-- 4 Kbytes in 1 Request.

Running postqueue -f repeats the problem.

I ran "perl-after-upgrade" which did not help. I then reinstalled everything that depends on Perl "portupgrade -fr perl". This also doesn't help.

Now I'm stuck... And need a little help from my friends :)
 
I ran into same problem and I wish never upgraded my Perl 5.8.xx to 5.10.1. I did fixed the issue by recompling all apps
Code: 
portmaster -r perl- /var/db/pkg/perl-5.10.1/

However, it did removed my maia ports, which I had to reinstall and restored config files from backup. Now it is working for me.
 
Yeah, the last couple of Perl upgrades haven't been painless. The 'perl-after-upgrade' command used to cut it, but I've grown used to running [cmd=]portmaster -Rr perl-5\*[/cmd] now.
 
Hey all!

I have exactly the same problem, none of the solutions posted here did the trick.

For the time being i disabled amavisd completly and send unfiltered emails.

Help is desperatly needed.

-Chris.
 
It is perl problem for sure.. I've restored my whole system and mailbox and it works nicely with Perl 5.8.xx series.
 
As mentioned in my previous post I already did a complete reinstall of perl and depended programs. This did not help.

I turned logging to full ($log_level = 5) in amavisd. No luck there.
Amavisd is crashing and thats why the connection is dropped. I suspect a dependency is missing or not fully upgraded.

Without any logging or other crash reports I'm searching for the needle in the haystack.
Is there a way figure out why amavisd on 127.0.0.1:10024 is crashing?
 
I just fixed this. Just now.
In a nutshell: (I was running perl 5.8)

1. make perl 5.10
2. remove perl 5.8
3. install perl 5.10
4. portupgrade -f p5*
5. perl-after-upgrade
6. make amavisd-new, make deinstall install
7. working :)

Yarrr!!

-Chris.
 
creiss said:
I just fixed this. Just now.
In a nutshell: (I was running perl 5.8)

1. make perl 5.10
2. remove perl 5.8
3. install perl 5.10
4. portupgrade -f p5*
5. perl-after-upgrade
6. make amavisd-new, make deinstall install
7. working :)

Yarrr!!

-Chris.
Click to expand...

Since I already removed perl 5.8 I'll start at 4 and see if this helps.
 
Same issue...

Strange, i have same issue too.

I removed & reinstalled amavisd-new, spamassassin, clamav but its not helped.

Have easy way without reinstalling perl fix this problem?

Thanks.
 
Creiss' solution workes.
Forcing upgrade of all p5 packages (portupgrade -f p5*) as Creiss suggested does the trick. But there's probably a faster way...

Before I upgraded I saved a list of all p5* packages. After the upgrade I compared this with my newly installed versions. This gave me 4 packages.
Code: 
p5-Class-MOP-0.93
p5-Convert-UUlib-1.32,1
p5-Moose-0.90
p5-Try-Tiny-0.02

I compared those with my last pkg_version list which cron mails me on a daily basis. Turns out that exactly those packages (except p5-Try-Tiny) need upgrading. Since p5-Moose-0.90 depends on p5-Try-Tiny-0.02 it is installed automagically.

Seems like they fixed the bug. So the quicker way would be to upgrade to the latest p5* port packages.
Code: 
portupgrade p5*

tail your messages file (tail -f /var/log/messages). In another terminal flush the queue (postqueue -f) and see if the error goes away.

If this doesn't work use Creiss' solution above.
 
hansaplast said:
Creiss' solution workes.
Forcing upgrade of all p5 packages (portupgrade -f p5*) as Creiss suggested does the trick. But there's probably a faster way...

Before I upgraded I saved a list of all p5* packages. After the upgrade I compared this with my newly installed versions. This gave me 4 packages.
Code: 
p5-Class-MOP-0.93
p5-Convert-UUlib-1.32,1
p5-Moose-0.90
p5-Try-Tiny-0.02

I compared those with my last pkg_version list which cron mails me on a daily basis. Turns out that exactly those packages (except p5-Try-Tiny) need upgrading. Since p5-Moose-0.90 depends on p5-Try-Tiny-0.02 it is installed automagically.

Seems like they fixed the bug. So the quicker way would be to upgrade to the latest p5* port packages.
Code: 
portupgrade p5*

tail your messages file (tail -f /var/log/messages). In another terminal flush the queue (postqueue -f) and see if the error goes away.

If this doesn't work use Creiss' solution above.
Click to expand...

Hmmm... Thank for Creiss for this solution. But it's takes many time and service downtime =((

All my ports up to date.

But problem still active.

Strange that, its appears with same user's. Other user can send mail normally. But sometimes all messages stuck on queue.
In this case i must reload postfix without content filter, flush queue. then i reload postfix again with content filter. =(((( i added this task to cron. but its not best way =(((
 
Nadir said:
Hmmm... Thank for Creiss for this solution. But it's takes many time and service downtime
Click to expand...

Normally when you run a live server, you should have a fallback server running on a different IP.
When registering your mail domains (MX records) your first MX record points to the main server. Your second MX record points to the fallback.

Unless your mailserver isn't used for internal mail (and clients are directly connected) you can shut it down without a problem and all mail will be dropped at the fallback. If you need the main server running for internal distribution you can upgrade after work hours.

If you don't have a fallback in a live situation. Get one or don't run a live mailserver. At some point you need to shut it down. All mail will be bounced, angry customers, etc.. and.. it doesn't look good on you cv.
 
hansaplast said:
Normally when you run a live server, you should have a fallback server running on a different IP.
When registering your mail domains (MX records) your first MX record points to the main server. Your second MX record points to the fallback.

Unless your mailserver isn't used for internal mail (and clients are directly connected) you can shut it down without a problem and all mail will be dropped at the fallback. If you need the main server running for internal distribution you can upgrade after work hours.

If you don't have a fallback in a live situation. Get one or don't run a live mailserver. At some point you need to shut it down. All mail will be bounced, angry customers, etc.. and.. it doesn't look good on you cv.
Click to expand...



I just fixed it =)))


Just I comment following decoders in amavisd.conf file and now all works fine =))))
Code: 
@decoders = (
  ['mail', \&do_mime_decode],
[B]#  ['asc',  \&do_ascii],
#  ['uue',  \&do_ascii],
#  ['hqx',  \&do_ascii],
#  ['ync',  \&do_ascii],[/B]
  ['F',    \&do_uncompress, ['unfreeze','freeze -d','melt','fcat'] ],
  ['Z',    \&do_uncompress, ['uncompress','gzip -d','zcat'] ],
.....
 
You must log in or register to reply here.
Back
Top