It's true I don't have your experience as you are the postfix coders.
But it's also true you don't know what can be my expericence.
Considering your political answers since the beginning, embarassing for who?
You're right that's enough. I'm going to answer you in private.
Envoyé de mon iPad
Le
> sorry, but after following the thread you are not qualified
> enough to judge design-patterns of a software you do not
> understand enough
I agree totally on that. That's why I write in the users mailing list, not in
the developpers mailing list.
To stop this thread that is borring for everybo
You're right that's enough and I'll answer you in private.
Wietse Venema a écrit :
> Nicolas HAHN:
>> The "archietcture" is not a good excuse for me, I'm sorry. As a
>> coder, allowing a software to start despite the fact there is a
>> FATAL is a total non-sens. And saying finally that is just a
Am 24.04.2013 19:45, schrieb Nicolas HAHN:
> The "archietcture" is not a good excuse for me, I'm sorry. As a coder
well, that's the difference between "coder" and "delevoper"
a "coder" writes something which works for now and every
few years all is thrown away because the architecture
and softw
Nicolas HAHN:
> The "archietcture" is not a good excuse for me, I'm sorry. As a
> coder, allowing a software to start despite the fact there is a
> FATAL is a total non-sens. And saying finally that is just a daemon
> which will not run but the others will, I really don't know how
> to take it...
On Wed, Apr 24, 2013 at 07:45:52PM +0200, Nicolas HAHN wrote:
> The "archietcture" is not a good excuse for me, I'm sorry.
You don't yet known enough about Postfix to appreciate the answer,
this is not your fault, but the design is fine.
--
Viktor.
The "archietcture" is not a good excuse for me, I'm sorry. As a coder, allowing
a software to start despite the fact there is a FATAL is a total non-sens. And
saying finally that is just a daemon which will not run but the others will, I
really don't know how to take it...
And you can daemonize
On Wed, Apr 24, 2013 at 05:23:09PM +0200, Nicolas HAHN wrote:
> > Can you post the fatal error messages you found, especially the
> > messages that log why the queue manager was restarting, as that
> > is the real problem.
>
> Here is what I found:
>
> 2013-04-24T10:04:38.005665+00:00 iccpfxor04
Yea. Thanks, i've seen it the first time you posted it.
But that's not for this reason I'll change my mind about this.
BR.
nicolas
Wietse Venema a écrit :
> Nicolas HAHN:
>> What I consider just abnormal as already written is that for me
>> (so it's my opinion), Postfix should refuse to start
Nicolas HAHN:
> What I consider just abnormal as already written is that for me
> (so it's my opinion), Postfix should refuse to start when it detects
> a fatal about a configuration issue in the config files. But it
> starts any way and display each minute the fatal in the log file.
If you think
> Can you post the fatal error messages you found, especially the
> messages that log why the queue manager was restarting, as that
> is the real problem.
Here is what I found:
2013-04-24T10:04:38.005665+00:00 iccpfxor04 postfix/local[9370]: fatal: main.cf
configuration error: mailbox_size_limit
On Wed, Apr 24, 2013 at 04:47:26PM +0200, Nicolas HAHN wrote:
> This is a reply to myself because I'm reviewing the way it works.
>
> > Yes, but if I'm right, the log message is emitted at the time there
> > is an e-mail processed (by postfix/local for my issue).
>
> In fact, the fatal is writt
This is a reply to myself because I'm reviewing the way it works.
> Yes, but if I'm right, the log message is emitted at the time there
> is an e-mail processed (by postfix/local for my issue).
In fact, the fatal is written in the logs each minute and 1 second for this
issue in my case by the
Nicolas HAHN:
> Yes, but if I'm right, the log message is emitted at the time there
> is an e-mail processed (by postfix/local for my issue).
>
> What I'm speaking about there is that postfix should check the
> configuration for this issue (for example) at the time it is started
> or its configura
This story also makes me think, suddenly, that I should integrate in my Log
Search Tool a feature allowing real time fatal error catching (and not only
fatal) form postfix logs and real time alerting of the users using the tool in
case a fatal comes during e-mail procesing. Will see that for ver
Yes, but if I'm right, the log message is emitted at the time there is an
e-mail processed (by postfix/local for my issue).
What I'm speaking about there is that postfix should check the configuration
for this issue (for example) at the time it is started or its configuration is
reloaded, and R
Nicolas HAHN:
> Postfix feature request: that would be nice that Postfix be able
> to do this kind of basic checks by itself when starting (or when
> configuration is reloaded) between various inter-dependent
> configuration settings, and display in the logs at least some
> warnings when such kind
> 1. Don't send bounces to postmaster, just generate and read log summaries
> that may highlight aggregate problems with your mail stream.
>
> notify_classes =
>
> This applies to any MTA handing mail for a large number of users,
> it is fine to have postmaster notices for a ma
On Wed, Apr 24, 2013 at 03:37:17PM +0200, Nicolas HAHN wrote:
> > More likely you have a mailbox size limit smaller than the message
> > size limit.
>
> Yes, that's the reason. I completely forgot to check the matching
> between both settings.
>
> The mailbox size limit was set to its default va
> More likely you have a mailbox size limit smaller than the message
> size limit.
Yes, that's the reason. I completely forgot to check the matching between both
settings.
The mailbox size limit was set to its default value of 50 Mb. After setting it
to 150 Mb, the issue was fixed.
Note: the b
Nicolas HAHN:
Content-Description: Version texte brut du message
[ Charset ISO-8859-1 unsupported, converting... ]
> OK.
>
> I did some tries and it seems that I cannot go above 40 Mb for
> message_size_limit to avoid the issue.
>
> As you wrote, here below is a set of log lines during the issu
On Wed, Apr 24, 2013 at 03:22:14PM +0200, Nicolas HAHN wrote:
> 2013-04-24T12:32:01.442962+00:00 iccpfxor04 postfix/qmgr[24391]: 6B34360BAA:
> from=, size=8389, nrcpt=1 (queue
> active)
> 2013-04-24T12:36:09.981198+00:00 iccpfxor04 postfix/qmgr[27126]: 6B34360BAA:
> from=, size=8389, nrcpt=1 (q
> Postfix memory usage does not depend on message size. Far more
> likely some filter has message size issues, or perhaps mailbox_size_limit
> has not been raised to match, or the OP failed to reload Postfix, so that
> the message size limit was different in some processes.
Each time I've reloade
Am 24.04.2013 15:22, schrieb Nicolas HAHN:
> As you wrote, here below is a set of log lines during the issue. The emails
> staying in the growing active queue are
> the bounce messages (we intercept them to send a copy to postmaster):
>
> [root@iccpfxor04 postfix]# grep 6B34360BAA /var/log/mail
OK.
I did some tries and it seems that I cannot go above 40 Mb for
message_size_limit to avoid the issue.
As you wrote, here below is a set of log lines during the issue. The emails
staying in the growing active queue are the bounce messages (we intercept them
to send a copy to postmaster):
[
Nicolas HAHN:
> I've modified message_size_limit from 20 Mb to 120 Mb this morning.
> I know that's not something to do and we explained to the customer
> a messaging system wasn't in any case a file transfer service...
> But after, politic came in and blablabla...
>
> And immediately after this ch
On Wed, Apr 24, 2013 at 03:07:05PM +0200, Reindl Harald wrote:
> Am 24.04.2013 14:58, schrieb Nicolas HAHN:
> > Does somebody knows what is happening?
>
> no because you missed to send any log-information
Definitely.
> maybe to less memory to proceed messages with 150 MB
Postfix memory usage
Am 24.04.2013 14:58, schrieb Nicolas HAHN:
> Does somebody knows what is happening?
no because you missed to send any log-information
maybe to less memory to proceed messages with 150 MB
signature.asc
Description: OpenPGP digital signature
Dear all,
I'm experiencing an issue now about message_size_limit.
I've modified message_size_limit from 20 Mb to 120 Mb this morning.
I know that's not something to do and we explained to the customer a messaging
system wasn't in any case a file transfer service... But after, politic came in
an
29 matches
Mail list logo
