Quanah,
Again, the only difference is 2.9.0 vs 2.10.1. I.e., we used the same
uulib library in 2.9.0 without these issues. Unless do_ascii was
modified between 2.9.0 and 2.10.1 to add uulib checks, this doesn't
seem
like it would be the source. I will go and remove it however, since
it
is
The change log to Convert::UUlib 1.50 shows:
Revision history for Perl extension Convert::UUlib.
1.5 Sat Jul 11 03:56:06 CEST 2015
- fix a heap overflow (testcase by Krzysztof WojtaĆ).
- on systems that support it (posix + mmap + map_anonymous),
allocate all dynamic areas via mmap
--On Wednesday, January 27, 2016 4:40 PM +0100 Mark Martinec
wrote:
The change log to Convert::UUlib 1.50 shows:
Revision history for Perl extension Convert::UUlib.
1.5 Sat Jul 11 03:56:06 CEST 2015
- fix a heap overflow (testcase by Krzysztof
--On Wednesday, January 27, 2016 4:26 PM +0100 Mark Martinec
wrote:
Quanah,
Again, the only difference is 2.9.0 vs 2.10.1. I.e., we used the same
uulib library in 2.9.0 without these issues. Unless do_ascii was
modified between 2.9.0 and 2.10.1 to add uulib
Quanah,
We recently updated to Amavisd 2.10.1 from 2.9.0 internally, and have
found that amavisd
constantly dies while processing messages after being put under a
moderate load in our
QA environment.
Jan 19 06:57:52 zqa-211 amavis-services[18544]: PID 13724 went away,
13724-01
The process
--On Wednesday, January 27, 2016 3:21 PM +0100 Mark Martinec
wrote:
There you go, the problem must be in do_ascii - which calls
Convert::UUlib,
which in turn uses the uulib library - which has been known to cause
crashes
in the past. It is ancient library, poorly
--On Wednesday, January 27, 2016 6:40 AM -0800 Quanah Gibson-Mount
wrote:
--On Wednesday, January 27, 2016 3:21 PM +0100 Mark Martinec
wrote:
There you go, the problem must be in do_ascii - which calls
Convert::UUlib,
which in turn uses the
--On Thursday, January 21, 2016 11:08 AM -0800 Quanah Gibson-Mount
wrote:
To be clear, this happens on any server (we have hundreds) if we put
amavis under load. They have plenty of memory, and are not running out.
I think this is related to the changes made here:
- use a
--On Tuesday, January 26, 2016 8:19 AM +1000 Noel Butler
wrote:
you might want to CC Marc directly - he hasn't posted in here in a very
log time, inn fact Oct 2014 is last time I think when he announced that
version, strange, since he posts regularly on postfix list
Yeah, a lot of people here have seem to have no luck, I think I
mentioned twice about a problem with no answer (gave up asking a third
time)
Maybe amavisd-new is going the same way as mailscanner, ie: abandonware
On 26/01/2016 08:31, Quanah Gibson-Mount wrote:
--On Tuesday, January 26, 2016
--On Tuesday, January 26, 2016 8:50 AM +1000 Noel Butler
wrote:
Yeah, a lot of people here have seem to have no luck, I think I mentioned
twice about a problem with no answer (gave up asking a third time)
Maybe amavisd-new is going the same way as mailscanner, ie:
you might want to CC Marc directly - he hasn't posted in here in a very
log time, inn fact Oct 2014 is last time I think when he announced that
version, strange, since he posts regularly on postfix list we know he's
still alive and kickin.
On 26/01/2016 04:48, Quanah Gibson-Mount wrote:
Yes, I agree, github would be perfect
On 26/01/2016 08:56, Quanah Gibson-Mount wrote:
--On Tuesday, January 26, 2016 8:50 AM +1000 Noel Butler
wrote:
Yeah, a lot of people here have seem to have no luck, I think I
mentioned
twice about a problem with no answer
--On Tuesday, January 19, 2016 10:39 PM -0700 Thomas Spuhler
wrote:
maybe worthwhile to look if it uses to daemonized version of clam (clamd
not clamav)
Thanks for the thought, but this doesn't appear to be the issue (See my
reply to Ben coming in shortly.
--On Tuesday, January 19, 2016 8:04 PM -0500 listsb-ama...@bitrate.net
wrote:
On Jan 19, 2016, at 18.09, Quanah Gibson-Mount wrote:
amavis-services[18544]: PID 13724 went away, 13724-01
does $log_level = 5 reveal any additional clues about what happened to
the process?
On Jan 19, 2016, at 18.09, Quanah Gibson-Mount wrote:
>
> We recently updated to Amavisd 2.10.1 from 2.9.0 internally, and have found
> that amavisd constantly dies while processing messages after being put under
> a moderate load in our QA environment.
>
> For example,
On Tuesday, January 19, 2016 08:04:50 PM listsb-ama...@bitrate.net wrote:
> On Jan 19, 2016, at 18.09, Quanah Gibson-Mount wrote:
> > We recently updated to Amavisd 2.10.1 from 2.9.0 internally, and have
> > found that amavisd constantly dies while processing messages after
17 matches
Mail list logo