Hi Thomas,
Cracked it. It turns out it is all down to debugging. I remembered I turned
that on at the same time as upgrading the version. I've turned that off
again and both ASSP instances are back up to full speed. Phew.
Not sure why debugging had such a major impact, it never has before and
I've been watching what the process is doing. It seems to be writing to the
logfiles, or failing to. I have this:
write(63, "2016-10-03 15:41:31 [Worker_7] <"..., 102) = 102
This repeats 999 times until:
write(63, "2016-10-03 15:41:39 [Worker_7] <"..., 101) = 101
There is no line with a
Hi Thomas,
I don't know what is going on. I've dropped back to 16275 and external
email starts working again but it is extremely slow. I can't get to the GUI
and output to the maillog is slow.
I've even dropped back to 16270 and it is still the same. Are there any
caches or database entries that
I'm sure, there is no change in build 16277 than can cause this.
Thomas
Von:cw
An: ASSP development mailing list
Datum: 03.10.2016 15:39
Betreff:Re: [Assp-test] fixes in assp 2.5.4 build 16277
Hi Thomas,
After
Okay, I'm back to standard logging on ClamAV then
Thanks
On Mon, Oct 3, 2016 at 2:55 AM, Thomas Eckardt
wrote:
> >1) Is verbose logging slowing things
>
> The MainThread goes slower than more is logged
>
> >1) and causing the daemon to be unreachable
>
> No.
>
>
Hi Thomas,
After upgrading to this build ASSP was only listening on my internal
private subnet and was not accepting connections from the outside world.
I've had to go straight back down to 16275.
On Mon, Oct 3, 2016 at 1:44 PM, Thomas Eckardt
wrote:
> Hi all,
>
>
Hi Thomas,
I've got 16277 running straight away. Oddly I've not been able to get
connected to the GUI on either server since upgrading I just get timeouts.
I'm not entirely convinced this build is working properly for me. I'm
seeing only one email every few minutes rather than the constant
>action: header (Content-Disposition -attr)
2.5.4 16277 will no longer use this output to state the worker
please post the line produced with the current build
"action: header (Content-Disposition -attr)" may be stated by a virus or
attachment check, done in the body check of assp.pl or the
Hi all,
fixed in assp 2.5.4 build 16277:
changed:
- for all SSL/TLS connection a 'read ahead' mechanism is implemented to
speed up mail processing
for small SSL-frame size (< 8kB) - at least by ten times
added:
- 'neverQueueSize','Never internaly Queue Mails larger than this Size'
Default
>Wouldn't it be better to have a "gliding" score, i.e. with every
nice idea - thrown away in 2008 for the PBBlack
for some temporary hashes (domainIP ... outgoing mail limiter ) it is
done this way
assume the IP has been connected 100 times - we'll get something like
time1 value1 time2
Hi Thomas,
thanks for explaining this behaviour. Let's see if I get this right...
Let's assume an IP reveals constant misbehaviour adding a PB-IP-Score of 60
every hour. It started off at 0 so after 6 hours (default PenaltyExpiration)
the score would be 360 and rising, but *surprise* after
Hi Thomas,
I've put 16275 on one of my servers this morning. I'm seeing the no running
workers error every 10-20 minutes causing ASSP to shut down. I've sat there
with the worker status page open and I'm not seeing any workers getting
stuck that coincide with this problem. In fact when the error
The PBBlack record is removed after 'PenaltyExpiration' minutes of the
record creation (NOT the last update).
Thomas
Von:"Dirk Kulmsee"
An: "'ASSP development mailing list'"
Datum: 03.10.2016 10:19
Betreff:Re:
Hi Thomas,
if there was a good message causing this, then I should see the IP in
question in my log before the drop. But there is not a single line.The score
is high, nothing happens, the score is low.
This happened again today and I grep'ed the log for e.g. 118.71.251
(leaving out the last
There are dozend of reasons why this can happen.
Most common is 'PenaltyExpiration'.
If there is a good mail transfered by an IP, the IP score is deleted to
prevent false positives. Where good means - no doubed, like 'contentOnly',
RWL, SPF, DKIM
Thomas.
Von:"Dirk Kulmsee"
>1) Is verbose logging slowing things
The MainThread goes slower than more is logged
>1) and causing the daemon to be unreachable
No.
>1) is this happening with standard logging too and just not
>logged?
Yes.
>2) Is this normal? If not, what should I do to fix this?
This is normal. Every
16 matches
Mail list logo