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 later. This also is not a good excuse. I take the Nagios example: [root@server nagios]# service nagios restart Running configuration check... CONFIG ERROR! Restart aborted. Check your Nagios configuration. [root@server nagios]# And after having fixed the configuration files: [root@server nagios]# service nagios restart Running configuration check...done. Stopping nagios: ...done. Starting nagios: done. [root@server nagios]# But OK I understand your points and will stop to post my blabla. /dev/rob0 <[email protected]> a écrit : > 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: > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
