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 postfix/local[9370]: > fatal: main.cf configuration error: mailbox_size_limit is smaller > than message_size_limit
Here, local(8) is having a fatal error. This error occurs whenever local (and probably virtual(8) as well) is invoked for delivery. Conversely, this error does NOT occur otherwise. The rest of the system might be fine. (Postfix has a modular design, BTW.) > 2013-04-24T10:04:39.006185+00:00 iccpfxor04 postfix/master[26402]: > warning: process /usr/libexec/postfix/local pid 9370 exit status 1 > 2013-04-24T10:04:39.006209+00:00 iccpfxor04 postfix/master[26402]: > warning: /usr/libexec/postfix/local: bad command startup -- > throttling And see, master(8) is doing fine, letting you know that there is a problem with local. [snip] > 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 This seems to betray a lack of understanding of the architecture. I think at this point you'd benefit from further study: http://www.postfix.org/OVERVIEW.html What about a system with no local/virtual delivery? Suppose delivery is via pipe(8) or lmtp(8)? Or suppose there are no hosted domains at all, merely a MSA/relay for other hosts? This fatal error in local won't ever affect such a system. > starts any way and display each minute the fatal in the log file. Every time local attempts to deliver. > It should display also a message on the console just before to There is no console, this is a daemon process detached from the terminal. > exit. But there are probably good reasons it is actually designed > like that. Yes. > That's for this reason I'm going to integrate warning and fatal > real time parsing in my tool for next coming version. That should > help to prevent this kind of behavior from lazzy SMTP admins :-D It's probably impossible to compensate for a sysadmin who lacks understanding of the system s/he is running. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
