Noel Jones:
> > Jul 9 14:32:10 mail postfix/master[3409]: terminating on
> > signal 15
>
>
> [Post in plain text only next time please -- no html]
>
> Postfix master process crashed.
No. The master received the SIGTERM signal, which Postfix
uses internally with "postfix stop".
If you don't wa
On Mon, Jul 11, 2011 at 1:10 PM, Noel Jones wrote:
>
> On 7/10/2011 8:17 PM, Alberto Lepe wrote:
> > This past days Amavis has been reporting some errors which
> > restart postfix daemon.
> > Does anyone know why is this happening? Is this important? How
> > can it be fixed?
> >
> > I'm using post
On 7/10/2011 8:17 PM, Alberto Lepe wrote:
> This past days Amavis has been reporting some errors which
> restart postfix daemon.
> Does anyone know why is this happening? Is this important? How
> can it be fixed?
>
> I'm using postfix 2.5.1-2ubuntu1.4 and amavis 2.5.3-1ubuntu3
> (Ubuntu Hardy)
>
This past days Amavis has been reporting some errors which restart postfix
daemon.
Does anyone know why is this happening? Is this important? How can it be
fixed?
I'm using postfix 2.5.1-2ubuntu1.4 and amavis 2.5.3-1ubuntu3 (Ubuntu Hardy)
I didn't change postfix settings recently and it was last
Wietse Venema wrote:
The 15-minute distance suggests that the system was already in
trouble long before the qmgr voluntarily exited with status 1.
True, it was only when the load began blocking processes for extended
amounts of time that the problems would occur. One of the monitors,
outputti
Jeroen van Aart:
> Wietse Venema wrote:
> > Jeroen van Aart:
> >> Yes I did:
> >> egrep '(warning|error|fatal|panic):' /var/log/mail.* | grep qmgr
> >> gunzip -c /var/log/mail.*.*.gz | egrep '(warning|error|fatal|panic):' |
> >> grep qmgr
> >
> > How much time is between the LAST qmgr[9582] logfi
Victor Duchovni wrote:
exit(1) is NOT a segfault. The queue manager exited voluntarily. Such
voluntary exists are typically (i.e. Postfix always tries) logged.
I understand. I was referring to unrelated processes which segfaulted
around the time postfix was having problems. Unexplained segfaul
On Wed, Aug 26, 2009 at 12:52:39PM -0700, Jeroen van Aart wrote:
> Wietse Venema wrote:
>> Jeroen van Aart:
>>> Yes I did:
>>> egrep '(warning|error|fatal|panic):' /var/log/mail.* | grep qmgr
>>> gunzip -c /var/log/mail.*.*.gz | egrep '(warning|error|fatal|panic):' |
>>> grep qmgr
>> How much tim
Wietse Venema wrote:
Jeroen van Aart:
Yes I did:
egrep '(warning|error|fatal|panic):' /var/log/mail.* | grep qmgr
gunzip -c /var/log/mail.*.*.gz | egrep '(warning|error|fatal|panic):' |
grep qmgr
How much time is between the LAST qmgr[9582] logfile record BEFORE
the master warning? If the
Jeroen van Aart:
> Yes I did:
> egrep '(warning|error|fatal|panic):' /var/log/mail.* | grep qmgr
> gunzip -c /var/log/mail.*.*.gz | egrep '(warning|error|fatal|panic):' |
> grep qmgr
How much time is between the LAST qmgr[9582] logfile record BEFORE
the master warning? If the distance is larg
Wietse Venema wrote:
I don't think so.
Instead of YOU filtering by hand a long file, let the COMPUTER do
the work for you:
egrep '(warning|error|fatal|panic):' /the/log/file | grep qmgr
I read the links provided and that's what I did. I filtered by hand
first and then grepped the logs to ve
Jeroen van Aart:
> That's it until
> Aug 15 02:55:06 prod101 postfix/master[9402]: warning: process
> /usr/lib/postfix/qmgr pid 9582 exit status 1
I don't think so.
Instead of YOU filtering by hand a long file, let the COMPUTER do
the work for you:
egrep '(warning|error|fatal|panic):' /the/log
Brian Evans - Postfix List wrote:
This is the real problem.
Search the logs just before this for a qmgr[9582] (error|fatal|panic).
Thanks for the pointer. I don't find any indication that qmgr was having
a problem, below are the last log entries:
Aug 15 02:08:31 prod101 postfix/qmgr[9582]:
Jeroen van Aart:
> Aug 15 02:55:06 prod101 postfix/master[9402]: warning: process
> /usr/lib/postfix/qmgr pid 9582 exit status 1
Good. Now look for error/fatal/warning loggings BEFORE this record.
Wietse
http://www.postfix.org/DEBUG_README.html#logging
Look for obvious signs of trouble
Jeroen van Aart wrote:
> Wietse Venema wrote:
>> It's unprodictive to kill off Postfix under overload. At the very
>> least you should increase your 35-second deadline.
>
> Yes I did increase it to 120 seconds. I understand just killing and
> restarting postfix is not a solution.
>
> As a test I sw
Wietse Venema wrote:
It's unprodictive to kill off Postfix under overload. At the very
least you should increase your 35-second deadline.
Yes I did increase it to 120 seconds. I understand just killing and
restarting postfix is not a solution.
As a test I switched the monitor to sending an a
Jeroen van Aart:
> I am pretty sure the babysitter does a few false restarts just because
> the system is overloaded and it's not getting a response soon enough.
> But without it you'd have an MTA less system for days. It's checking
> connectivity on 127.0.0.1:25 with a timeout of 35 seconds, wh
Wietse Venema wrote:
Postfix usually logs an error if it cannot proceed. What are the
logfile symptoms (excluding those caused by your babysitter)?
Around the time the problems start there are far less log entries of
postfix. And it's always writing log entries since it's a busy server.
That
Jeroen van Aart:
> Wietse Venema wrote:
> > Postfix has proven to be rock solid, and there is no need to
> > make it less reliable with trigger-happy babysitters.
>
> I am not giving any value judgement to postfix. In fact it's one of the
> few MTAs I would trust to run on any systems I manage.
Wietse Venema wrote:
Postfix has proven to be rock solid, and there is no need to
make it less reliable with trigger-happy babysitters.
I am not giving any value judgement to postfix. In fact it's one of the
few MTAs I would trust to run on any systems I manage.
The problem is not postfix, i
Jeroen van Aart:
> Wietse Venema wrote:
> > Internally, "postfix stop" uses SIGTERM to terminate the master
> > daemon. This signal is also used by system shutdown procedures.
>
> Right, the monitor will use /etc/init.d/postfix stop|start in order to
> attempt to restart postfix.
Postfix has pr
Wietse Venema wrote:
Internally, "postfix stop" uses SIGTERM to terminate the master
daemon. This signal is also used by system shutdown procedures.
Right, the monitor will use /etc/init.d/postfix stop|start in order to
attempt to restart postfix.
Greetings,
Jeroen
Jeroen van Aart:
> I should add that I was miss interpreting the "terminating on signal
> 15". That in fact is my monitor doing its work, which I installed after
> noticing postfix would regularly quit. It's likely the actual kill
Internally, "postfix stop" uses SIGTERM to terminate the master
Bastian Blank wrote:
On Wed, Aug 12, 2009 at 05:23:17PM -0700, Jeroen van Aart wrote:
I am not sure if it's the kernel's OOM killer or postfix itself which
causes it to quit.
1. The OOM killer _always_ uses SIGKILL. A program is not even given the
possibility to react.
2. root processes (like
On Wed, Aug 12, 2009 at 05:23:17PM -0700, Jeroen van Aart wrote:
> I am not sure if it's the kernel's OOM killer or postfix itself which
> causes it to quit.
1. The OOM killer _always_ uses SIGKILL. A program is not even given the
possibility to react.
2. root processes (like master) have a much l
On Wed, 12 Aug 2009, Jeroen van Aart wrote:
> I am not sure if it's the kernel's OOM killer or postfix itself which
> causes it to quit. I do not see a mention in /var/log/messages about the
> OOM killer killing postfix, but I do see a mention in /var/log/mail.info
> about reading "postfix/maste
Server is debian lenny 64 bits, 32 GB, 4 CPU cores. Postfix package is
version 2.5.5-1.1
The above mentioned server has a problem that postfix keeps terminating
at regular intervals. I believe I have narrowed the problem down to a
program eating a lot of memory, likely due to multiple forks ea
27 matches
Mail list logo
