Loading ...
Sorry, an error occurred while loading the content.

292815Re: Message_size_limit issue with postfix v 2.8.8-1 on RHEL 6

Expand Messages
  • /dev/rob0
    Apr 24 9:02 AM
      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.

      > 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:


      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

      > exit. But there are probably good reasons it is actually designed
      > like that.


      > 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:
    • Show all 29 messages in this topic