To apply this patch, cd into the Postfix-2.5.* top-level source
directory and execute:
$ patch thismessage
We were able to reproduce the scheduler looping problem, and it
does not recur with the patched version
A question ... what' the way to make this patch to be included in
Ubuntu
On Fri, 06 Mar 2009 10:07:26 +0100
Santiago Romero srom...@servicom2000.com wrote:
A question ... what' the way to make this patch to be included in
Ubuntu Server postfix packages?
I mean, should I submit your message+patch to the package maintainers
of Ubuntu / Debian / Redhat so that new
Gerard escribió:
In a perfect world, the program maintainers would know about the patch
and take steps to correct their package/port or whatever. You might
want to contact the maintainer of Postfix for your Distro and see if
they are planning on updating the package/port. Usually, they do get a
Santiago Romero:
To apply this patch, cd into the Postfix-2.5.* top-level source
directory and execute:
$ patch thismessage
We were able to reproduce the scheduler looping problem, and it
does not recur with the patched version
A question ... what' the way to make this patch to
Wietse Venema wrote:
You might want to repeat your precise Postfix version at this point,
and which queue manager version is configured in your master.cf.
Current Postfix versions have (qmgr=new, oqmgr=old) in master.cf.
Older Postfix versions have (nqmgr=new, qmgr=old) instead. The
Santiago Romero:
(I mean, setting rate_ values higher or lower so that the problem
reproduces again faster, because it passed 5 days between the last 2
times qmgr ate the CPU...).
Just run the same test.
Thanks,
Wietse
On Thu, Mar 05, 2009 at 12:20:06PM +0100, Santiago Romero wrote:
Well, I'm using postfix's ubuntu package, so it's not compiled from source
code because I need all my ~=100 Linux machines to be easily updatable
(apt-get update apt-get upgrade).
In this case, I'm going to recompile .deb
Please wait for an updated patch, we believe we have identified the
cause and reproduced the symptoms (in that order). I have a candidate
patch, but I expect Wietse will send an updated more polished version
in the not too distant future.
Ok, I'll wait for it. I'm going to roll back to
On Thu, Mar 05, 2009 at 04:21:01PM +0100, Santiago Romero wrote:
Please wait for an updated patch, we believe we have identified the
cause and reproduced the symptoms (in that order). I have a candidate
patch, but I expect Wietse will send an updated more polished version
in the not too
Santiago Romero:
Please wait for an updated patch, we believe we have identified the
cause and reproduced the symptoms (in that order). I have a candidate
patch, but I expect Wietse will send an updated more polished version
in the not too distant future.
Ok, I'll wait for it.
On Thu, 5 Mar 2009 13:03:11 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
It will be later today. I don't have much time so I want to have
it really right the first time. Code that is right takes more work
than code that works.
Reminds me of a plaque I have in my office.
There
Wietse Venema:
Santiago Romero:
Please wait for an updated patch, we believe we have identified the
cause and reproduced the symptoms (in that order). I have a candidate
patch, but I expect Wietse will send an updated more polished version
in the not too distant future.
Wietse Venema escribió:
Santiago Romero:
I case it happens again ... Where or what should I take a look? At OS
level (disk or network I/O, processes...) I didn't see anything before
the postfix restart...
Try ``strace -o filename -p pid'' or the equivalent for your OS.
Hi.
On Wed, Mar 04, 2009 at 10:15:05AM +0100, Santiago Romero wrote:
/etc/postfix/master.cf
slow unix - - - - - smtp
-o syslog_name=postfix-slow
/etc/postfix/main.cf
# Special slow transport:
slow_destination_recipient_limit=1
A really BAD
Santiago Romero:
Stracing qmgr process for a while (before restarting postfix), showed
lots of lines like:
time(NULL) = 1236156322
epoll_ctl(8, EPOLL_CTL_DEL, 128, {EPOLLIN, {u32=128,
u64=13252642876283682944}}) = 0
fcntl64(128, F_GETFL) =
Victor Duchovni:
Is it the queue manager that's burning CPU? Nothing too interesting
here.
Yes, according to this:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
26926 postfix 20 0 5840 2552 1792 R 43 0.3 276:51.22 qmgr
There needs to be a safety check for the
Victor Duchovni:
slow_destination_recipient_limit=1
slow_destination_concurrency_limit=1
I wonder if the problem recurs when these are changed. But let's
first swap new and old queue managers.
Wietse
Santiago Romero:
Wietse Venema escribi?:
Santiago Romero:
I case it happens again ... Where or what should I take a look? At OS
level (disk or network I/O, processes...) I didn't see anything before
the postfix restart...
Try ``strace -o filename -p pid'' or the
Hi.
Today I had a load average issue in a postfix mail server (only runs
postfix service). Suddenly, load average started to raise and qmgr
process appeared on top of top taking 20-30% of CPU.
top - 18:19:54 up 7 days, 2:03, 2 users, load average: 4.94, 3.96, 4.02
Tasks: 144 total, 6
Santiago Romero:
I case it happens again ... Where or what should I take a look? At OS
level (disk or network I/O, processes...) I didn't see anything before
the postfix restart...
Try ``strace -o filename -p pid'' or the equivalent for your OS.
Wietse
20 matches
Mail list logo
