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

Postfix keeps all inbound & outbound mail in queue without any error in logs!!! (?!?!)

Expand Messages
  • XYZFounder
    Hi, I am running a debian 7 server. All good. I guess after an recent generel server update (may not be linked) rsyslog and postfix stop to really be working.
    Message 1 of 16 , Jul 16, 2014
    • 0 Attachment


      Hi,

      I am running a debian 7 server. All good. I guess after an recent generel server update (may not be linked) rsyslog and postfix stop to really be working.

      rsyslog could not be started and was fixed with rsyslogd -c5 so that log functionality returned.

      But with postfix all inbound messages are put to queue with * but get never put into mail directory.
      When running check there was an issue for one of my virtual domains, that there was no dkim signature. it complained about permissions.
      Afterall I excluded in main.conf of postix the use of dkim. Still postfix keeps them all in the active queue...

      And the s t r a n g e thing is: NO error in logs mail.log, mail.err, etc.)
      When I use on the server a locel user like root the maildrop seems to work (at times).
      I have checked the mysql databases, no error.

      When I send an email to my server (virtual domain) with a fake name, it gets correctly bounced back no such user in virtual table.

      This is what the logs share eventually: syslog: postfix/qmgr[26950]: B0FEA381A49: from=<mailer_user@my_virtual-domain>, size=1107, nrcpt=1 (queue active)


      Any advice where to start fixing this?! Yes, flushing no cure. I once did with a filled queue an hold and release, then the deferred messages all were gone! is there some
      dead.letter location to be finding them again?!

      THX,
      Jimbo

      --
      via www.LinuxMint.com 16:Petra
    • Viktor Dukhovni
      ... Fix logging first. If Postfix services are chrooted, make sure there is a log socket in the chroot jail or disable chroot. Once logging is working, come
      Message 2 of 16 , Jul 16, 2014
      • 0 Attachment
        On Thu, Jul 17, 2014 at 05:06:02AM +0200, XYZFounder wrote:

        > [long list of anecdotal problems]

        Fix logging first. If Postfix services are chrooted, make sure
        there is a log socket in the chroot jail or disable chroot. Once
        logging is working, come back with specific questions about one
        issue at a time. Without logging, no further help is possible.

        --
        Viktor.
      • XYZFounder
        logging works as said b4: https://workaround.org/ispmail/wheezy/connecting-postfix-to-the-database = all mysql works. postqueue -vv -f 2 &1 | tee
        Message 3 of 16 , Jul 16, 2014
        • 0 Attachment

          logging works as said b4:

          https://workaround.org/ispmail/wheezy/connecting-postfix-to-the-database => all mysql works.

          postqueue -vv  -f 2>&1 | tee /tmp/output.txt (see attachment).

          All mail in queue is marked with * but no delivery:

          THX,
          J


          PS: mail.log entries like:

          Jul 17 07:15:03 gFort postfix/pickup[7509]: ACCF5381C38: uid=33 from=<www-data>
          Jul 17 07:15:03 gFort postfix/cleanup[32491]: ACCF5381C38: message-id=<bw_65f89159d8fa80aae2bf5a0d24d6598e5cf57b8e@[my_domain]
          Jul 17 07:15:03 gFort postfix/qmgr[7510]: ACCF5381C38: from=<www-data@mail.[my_domain]>, size=2166, nrcpt=1 (queue active)



          via www.LinuxMint.com 16:Petra
          Am 17.07.2014 05:18, schrieb Viktor Dukhovni:
          On Thu, Jul 17, 2014 at 05:06:02AM +0200, XYZFounder wrote:
          
          
          [long list of anecdotal problems]
          
          Fix logging first.  If Postfix services are chrooted, make sure
          there is a log socket in the chroot jail or disable chroot.  Once
          logging is working, come back with specific questions about one
          issue at a time.  Without logging, no further help is possible.
          
          

        • XYZFounder
          I am soon leaving this great list again. If anybody has a clue and is willing to share, drop me a note directly.. J *via www.LinuxMint.com 16:Petra*
          Message 4 of 16 , Jul 17, 2014
          • 0 Attachment
            I am soon leaving this great list again. If anybody has a clue and is willing to share, drop me a note directly..

            J

            via www.LinuxMint.com 16:Petra
            Am 17.07.2014 07:19, schrieb XYZFounder:

            logging works as said b4:

            https://workaround.org/ispmail/wheezy/connecting-postfix-to-the-database => all mysql works.

            postqueue -vv  -f 2>&1 | tee /tmp/output.txt (see attachment).

            All mail in queue is marked with * but no delivery:

            THX,
            J


            PS: mail.log entries like:

            Jul 17 07:15:03 gFort postfix/pickup[7509]: ACCF5381C38: uid=33 from=<www-data>
            Jul 17 07:15:03 gFort postfix/cleanup[32491]: ACCF5381C38: message-id=<bw_65f89159d8fa80aae2bf5a0d24d6598e5cf57b8e@[my_domain]
            Jul 17 07:15:03 gFort postfix/qmgr[7510]: ACCF5381C38: from=<www-data@mail.[my_domain]>, size=2166, nrcpt=1 (queue active)



            via www.LinuxMint.com 16:Petra
            Am 17.07.2014 05:18, schrieb Viktor Dukhovni:
            On Thu, Jul 17, 2014 at 05:06:02AM +0200, XYZFounder wrote:
            
            
            [long list of anecdotal problems]
            
            Fix logging first.  If Postfix services are chrooted, make sure
            there is a log socket in the chroot jail or disable chroot.  Once
            logging is working, come back with specific questions about one
            issue at a time.  Without logging, no further help is possible.
            
            


          • Wietse Venema
            ... Jul 17 07:15:03 gFort postfix/qmgr[7510]: ACCF5381C38.... And: All mail in queue is marked with * but no delivery This suggests that the queue manager is
            Message 5 of 16 , Jul 17, 2014
            • 0 Attachment
              XYZFounder:
              > I am soon leaving this great list again. If anybody has a clue and is
              > willing to share, drop me a note directly..

              Jul 17 07:15:03 gFort postfix/qmgr[7510]: ACCF5381C38....

              And:

              All mail in queue is marked with * but no delivery

              This suggests that the queue manager is running, but the delivery
              agents (such as the smtp client for remote delivery) are not
              delivering mail. As a next step you need to tell us if they are
              running or not after "postqueue -f".

              Wietse
            • XYZFounder
              ... *via www.LinuxMint.com 16:Petra*
              Message 6 of 16 , Jul 17, 2014
              • 0 Attachment

                here:
                root@gFort:/etc/postfix# postqueue -f
                root@gFort:/etc/postfix# ps aux | grep virtual
                root      9240  0.0  0.0  12232   936 pts/3    S+   20:48   0:00 grep virtual
                postfix  20024  0.0  0.0  59372  2232 ?        T    Jul14   0:00 virtual -t unix
                postfix  30550  0.0  0.1  59372  3296 ?        S    20:00   0:00 virtual -t unix -v
                root@gFort:/etc/postfix# ps aux | grep smtp
                root      9760  0.0  0.0  12232   936 pts/3    S+   20:48   0:00 grep smtp
                postfix  20021  0.0  0.0  44248  1800 ?        T    Jul14   0:00 smtp -t unix -u -c
                postfix  24707  0.0  0.2 128384  7108 ?        S    20:03   0:01 smtpd -n submission -t inet -u -c -o stress= -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING
                postfix  30554  0.0  0.0  44248  2548 ?        S    20:00   0:00 smtp -t unix -u -c -vv
                root@gFort:/etc/postfix# 



                via www.LinuxMint.com 16:Petra
                Am 17.07.2014 20:35, schrieb Wietse Venema:

                    Jul 17 07:15:03 gFort postfix/qmgr[7510]: ACCF5381C38....
                
                And:
                
                    All mail in queue is marked with * but no delivery
                
                This suggests that the queue manager is running, but the delivery
                agents (such as the smtp client for remote delivery) are not
                delivering mail. As a next step you need to tell us if they are
                running or not after "postqueue -f".
                
                	Wietse
                

              • Wietse Venema
                ... Configured in this way. the SMTP client runs in a chroot jail. Turn that off in master.cf. #
                Message 7 of 16 , Jul 17, 2014
                • 0 Attachment
                  XYZFounder:
                  > > postfix 30554 0.0 0.0 44248 2548 ? S 20:00 0:00 smtp
                  > > -t unix -u -c -vv

                  Configured in this way. the SMTP client runs in a chroot jail. Turn
                  that off in master.cf.

                  # ==========================================================================
                  # service type private unpriv chroot wakeup maxproc command + args
                  # (yes) (yes) (yes) (never) (50)
                  # ==========================================================================
                  ...
                  smtp unix - - n - - smtp

                  The chroot column must be "n" for all programs.

                  Then "postfix reload", and you should have some logging.

                  Wietse
                • XYZFounder
                  THANKS: I had read about jail root, but did not know it shall be n for all programs. I will do that and then keep you posted ;) J PS: Jul 17 21:03:02 gFort
                  Message 8 of 16 , Jul 17, 2014
                  • 0 Attachment
                    THANKS: I had read about jail root, but did not know it shall be "n" for all programs.

                    I will do that and then keep you posted ;)

                    J

                    PS: Jul 17 21:03:02 gFort postfix/smtpd[13967]: dict_mysql_get_active: attempting to connect to host 127.0.0.1
                    Jul 17 21:03:02 gFort postfix/smtpd[13967]: dict_mysql: successful connection to host 127.0.0.1
                    Jul 17 21:03:02 gFort postfix/smtpd[13967]: dict_mysql: successful query from host 127.0.0.1
                    Jul 17 21:03:02 gFort postfix/smtpd[13967]: dict_mysql_lookup: retrieved 1 rows
                    Jul 17 21:03:02 gFort postfix/smtpd[13967]: maps_find: virtual_alias_maps: mysql:/etc/postfix/mysql-virtual_alias_maps.cf(0,lock|fold_fix): [virtual domain]
                    Jul 17 21:03:02 gFort postfix/smtpd[13967]: mail_addr_find: [virtual domain]
                    Jul 17 21:03:02 gFort postfix/smtpd[13967]: before input_transp_cleanup: cleanup flags = enable_header_body_filter enable_automatic_bcc enable_address_mapping enable_milters
                    Jul 17 21:03:02 gFort postfix/smtpd[13967]: after input_transp_cleanup: cleanup flags = enable_header_body_filter enable_automatic_bcc enable_address_mapping
                    Jul 17 21:03:02 gFort postfix/smtpd[13967]: connect to subsystem public/cleanup

                    via www.LinuxMint.com 16:Petra
                    Am 17.07.2014 21:01, schrieb Wietse Venema:
                    XYZFounder:
                    
                    postfix  30554  0.0  0.0  44248  2548 ?        S    20:00   0:00 smtp
                    -t unix -u -c -vv
                    
                    Configured in this way. the SMTP client runs in a chroot jail. Turn
                    that off in master.cf.
                    
                    # ==========================================================================
                    # service type  private unpriv  chroot  wakeup  maxproc command + args
                    #               (yes)   (yes)   (yes)   (never) (50)
                    # ==========================================================================
                    ...
                    smtp      unix  -       -       n       -       -       smtp
                    
                    The chroot column must be "n" for all programs.
                    
                    Then "postfix reload", and you should have some logging.
                    
                    	Wietse
                    

                  • XYZFounder
                    Hi Wietse Venema: I get output in the logs but nothing (no error) why it is held (still) in the queue. BTW Could one somehow bad email holt up the entire
                    Message 9 of 16 , Jul 17, 2014
                    • 0 Attachment
                      Hi Wietse Venema:

                      I get output in the logs but nothing (no error) why it is held (still) in the queue. BTW Could one somehow bad email holt up the entire queue?!

                      Jul 17 21:16:00 gFort postfix/smtpd[32024]: master_notify: status 1
                      Jul 17 21:16:00 gFort postfix/smtpd[32024]: connection closed
                      Jul 17 21:16:00 gFort postfix/smtpd[32024]: watchdog_stop: 0x7fbd30c9da10
                      Jul 17 21:16:00 gFort postfix/smtpd[32024]: watchdog_start: 0x7fbd30c9da10
                      Jul 17 21:16:03 gFort postfix/smtpd[32024]: auto_clnt_close: disconnect private/tlsmgr stream
                      Jul 17 21:16:03 gFort postfix/smtpd[32024]: rewrite stream disconnect
                      Jul 17 21:16:03 gFort postfix/smtpd[32024]: watchdog_stop: 0x7fbd30c9da10
                      Jul 17 21:16:03 gFort postfix/smtpd[32024]: watchdog_start: 0x7fbd30c9da10

                      so should there be coming forth anything after postfix/smtpd?! The qmnr again?!


                      via www.LinuxMint.com 16:Petra
                      Am 17.07.2014 21:01, schrieb Wietse Venema:
                      XYZFounder:
                      
                      postfix  30554  0.0  0.0  44248  2548 ?        S    20:00   0:00 smtp
                      -t unix -u -c -vv
                      
                      Configured in this way. the SMTP client runs in a chroot jail. Turn
                      that off in master.cf.
                      
                      # ==========================================================================
                      # service type  private unpriv  chroot  wakeup  maxproc command + args
                      #               (yes)   (yes)   (yes)   (never) (50)
                      # ==========================================================================
                      ...
                      smtp      unix  -       -       n       -       -       smtp
                      
                      The chroot column must be "n" for all programs.
                      
                      Then "postfix reload", and you should have some logging.
                      
                      	Wietse
                      

                    • XYZFounder
                      ... Hint: local delivery to mailboxes like root@localhost do work. So in the above I see that after the qmgr postfix local ist called. hence for the
                      Message 10 of 16 , Jul 17, 2014
                      • 0 Attachment
                        Jul 17 21:28:54 gFort postfix/pickup[29327]: 1C5E9381DD2: uid=0 from=<root@MY_ACTUAL_DOMAIN>
                        Jul 17 21:28:54 gFort postfix/cleanup[31587]: 1C5E9381DD2: message-id=<mutt698862573_20140717T210158@>
                        Jul 17 21:28:54 gFort postfix/qmgr[29328]: 1C5E9381DD2: from=<root@MY_ACTUAL_DOMAIN>, size=1037, nrcpt=1 (queue active)
                        Jul 17 21:28:54 gFort postfix/local[31608]: 1C5E9381DD2: to=<root@[SNIP]>, orig_to=<root@localhost>, relay=local, delay=0.17, delays=0.13/0.03/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)


                        Hint: local delivery to mailboxes like root@localhost do work. So in the above I see that after the qmgr postfix local ist called. hence for the virtualdomains postfix/virtual is missing?!

                        root@gFort:/etc/mystuff# ps aux | grep virtual
                        postfix  20024  0.0  0.0  59372  2232 ?        T    Jul14   0:00 virtual -t unix
                        root     26648  0.0  0.0  12236   952 pts/9    S+   21:32   0:00 grep virtual
                        postfix  29346  0.0  0.1  59372  3264 ?        S    21:14   0:00 virtual -t unix

                        could it be that an OLD virtual instance is messing things up?!

                        via www.LinuxMint.com 16:Petra
                        Am 17.07.2014 21:22, schrieb XYZFounder:
                        Hi Wietse Venema:

                        I get output in the logs but nothing (no error) why it is held (still) in the queue. BTW Could one somehow bad email holt up the entire queue?!

                        Jul 17 21:16:00 gFort postfix/smtpd[32024]: master_notify: status 1
                        Jul 17 21:16:00 gFort postfix/smtpd[32024]: connection closed
                        Jul 17 21:16:00 gFort postfix/smtpd[32024]: watchdog_stop: 0x7fbd30c9da10
                        Jul 17 21:16:00 gFort postfix/smtpd[32024]: watchdog_start: 0x7fbd30c9da10
                        Jul 17 21:16:03 gFort postfix/smtpd[32024]: auto_clnt_close: disconnect private/tlsmgr stream
                        Jul 17 21:16:03 gFort postfix/smtpd[32024]: rewrite stream disconnect
                        Jul 17 21:16:03 gFort postfix/smtpd[32024]: watchdog_stop: 0x7fbd30c9da10
                        Jul 17 21:16:03 gFort postfix/smtpd[32024]: watchdog_start: 0x7fbd30c9da10

                        so should there be coming forth anything after postfix/smtpd?! The qmnr again?!


                        via www.LinuxMint.com 16:Petra
                        Am 17.07.2014 21:01, schrieb Wietse Venema:
                        XYZFounder:
                        
                        postfix  30554  0.0  0.0  44248  2548 ?        S    20:00   0:00 smtp
                        -t unix -u -c -vv
                        
                        Configured in this way. the SMTP client runs in a chroot jail. Turn
                        that off in master.cf.
                        
                        # ==========================================================================
                        # service type  private unpriv  chroot  wakeup  maxproc command + args
                        #               (yes)   (yes)   (yes)   (never) (50)
                        # ==========================================================================
                        ...
                        smtp      unix  -       -       n       -       -       smtp
                        
                        The chroot column must be "n" for all programs.
                        
                        Then "postfix reload", and you should have some logging.
                        
                        	Wietse
                        


                      • Wietse Venema
                        ... You have too much noise in the mail.log file. Remove all the -v options from master.cf, do postfix reload , postfix flush , and wait for a few minutes.
                        Message 11 of 16 , Jul 17, 2014
                        • 0 Attachment
                          XYZFounder:
                          > Hi Wietse Venema:
                          >
                          > I get output in the logs but nothing (no error) why it is held (still)
                          > in the queue. BTW Could one somehow bad email holt up the entire queue?!

                          You have too much noise in the mail.log file.

                          Remove all the -v options from master.cf, do "postfix reload",
                          "postfix flush", and wait for a few minutes. If the logging does
                          not explain what is wrong, you can come back.

                          Wietse
                        • XYZFounder
                          ... *via www.LinuxMint.com 16:Petra*
                          Message 12 of 16 , Jul 17, 2014
                          • 0 Attachment
                            6549.948631801:7f1e801ec700: pipe (3) write error 11: Resource temporarily unavailable
                            6549.948709925:7f1e801ec700: Action 0x773f30 transitioned to state: rtry
                            6549.948786551:7f1e801ec700: action 0x773f30 call returned -2007
                            6549.948861671:7f1e801ec700: tryDoAction: unexpected error code -2007[nElem 1, Commited UpTo 0], finalizing
                            6549.948991887:7f1e801ec700: XXXXX:  tryDoAction 0x773f30, pnElem 1, nElem 1
                            6549.949140615:7f1e801ec700: Action 0x773f30 transitioned to state: rdy
                            6549.949263111:7f1e801ec700: Action 0x773f30 transitioned to state: itx
                            6549.949391877:7f1e801ec700: entering actionCalldoAction(), state: itx
                            6549.949521873:7f1e801ec700:  (/dev/xconsole)
                            6549.949654641:7f1e801ec700: pipe (3) write error 11: Resource temporarily unavailable
                            6549.949783825:7f1e801ec700: Action 0x773f30 transitioned to state: rtry
                            6549.949908361:7f1e801ec700: action 0x773f30 call returned -2007
                            6549.950038075:7f1e801ec700: tryDoAction: unexpected error code -2007[nElem 1, Commited UpTo 0], finalizing
                            6549.950165327:7f1e801ec700: XXXXX:  tryDoAction 0x773f30, pnElem 1, nElem 1
                            6549.950295411:7f1e801ec700: Action 0x773f30 transitioned to state: susp
                            6549.950424235:7f1e801ec700: earliest retry=1405626579
                            6549.950547990:7f1e801ec700: actionTryResume: action 0x773f30 state: susp, next retry (if applicable): 1405626579 [now 1405626549]
                            6549.950670278:7f1e801ec700: action 0x773f30 call returned -2123
                            6549.950791526:7f1e801ec700: tryDoAction: unexpected error code -2123[nElem 1, Commited UpTo 0], finalizing
                            6549.950918380:7f1e801ec700: actionTryResume: action 0x773f30 state: susp, next retry (if applicable): 1405626579 [now 1405626549]
                            6549.951047467:7f1e801ec700: ruleset: get iRet 0 from rule.ProcessMsg()
                            6549.951176003:7f1e801ec700: ruleset.ProcessMsg() returns 0
                            6549.951304871:7f1e801ec700: regular consumer finished, iret=0, szlog 2 sz phys 3
                            6549.951450891:7f1e801ec700: we deleted 1 objects and enqueued 0 objects
                            6549.951581801:7f1e801ec700: delete batch from store, new sizes: log 2, phys 2
                            6549.951714407:7f1e801ec700: processBatch: batch of 2 elements must be processed
                            6549.951842101:7f1e801ec700: Processing next rule
                            6549.951976131:7f1e801ec700: testing filter, f_pmask 255
                            6549.952129821:7f1e801ec700: testing filter, f_pmask 255
                            6549.952262169:7f1e801ec700: Processing next action
                            6549.952391831:7f1e801ec700: Called action(NotAllMark), processing batch[0] via 'builtin-file'
                            6549.952519223:7f1e801ec700: Called action(NotAllMark), processing batch[1] via 'builtin-file'
                            6549.952646815:7f1e801ec700: Called action(Batch), logging to builtin-file
                            6549.952783805:7f1e801ec700: XXXXX:  tryDoAction 0x7677e0, pnElem 2, nElem 2




                            via www.LinuxMint.com 16:Petra
                            Am 17.07.2014 21:36, schrieb Wietse Venema:
                            XYZFounder:
                            
                            Hi Wietse Venema:
                            
                            I get output in the logs but nothing (no error) why it is held (still)
                            in the queue. BTW Could one somehow bad email holt up the entire queue?!
                            
                            You have too much noise in the mail.log file.
                            
                            Remove all the -v options from master.cf, do "postfix reload",
                            "postfix flush", and wait for a few minutes. If the logging does
                            not explain what is wrong, you can come back.
                            
                            	Wietse
                            

                          • lists@rhsoft.net
                            what exactly in Remove all the -v options from master.cf was unlcear? that is still a cluttered debug log
                            Message 13 of 16 , Jul 17, 2014
                            • 0 Attachment
                              what exactly in "Remove all the -v options from master.cf" was unlcear?
                              that is still a cluttered debug log

                              Am 17.07.2014 21:50, schrieb XYZFounder:
                              >> 6549.948631801:7f1e801ec700: pipe (3) write error 11: Resource temporarily unavailable
                              >> 6549.948709925:7f1e801ec700: Action 0x773f30 transitioned to state: rtry
                              >> 6549.948786551:7f1e801ec700: action 0x773f30 call returned -2007
                              >> 6549.948861671:7f1e801ec700: tryDoAction: unexpected error code -2007[nElem 1, Commited UpTo 0], finalizing
                              >> 6549.948991887:7f1e801ec700: XXXXX: tryDoAction 0x773f30, pnElem 1, nElem 1
                              >> 6549.949140615:7f1e801ec700: Action 0x773f30 transitioned to state: rdy
                              >> 6549.949263111:7f1e801ec700: Action 0x773f30 transitioned to state: itx
                              >> 6549.949391877:7f1e801ec700: entering actionCalldoAction(), state: itx
                              >> 6549.949521873:7f1e801ec700: (/dev/xconsole)
                              >> 6549.949654641:7f1e801ec700: pipe (3) write error 11: Resource temporarily unavailable
                              >> 6549.949783825:7f1e801ec700: Action 0x773f30 transitioned to state: rtry
                              >> 6549.949908361:7f1e801ec700: action 0x773f30 call returned -2007
                              >> 6549.950038075:7f1e801ec700: tryDoAction: unexpected error code -2007[nElem 1, Commited UpTo 0], finalizing
                              >> 6549.950165327:7f1e801ec700: XXXXX: tryDoAction 0x773f30, pnElem 1, nElem 1
                              >> 6549.950295411:7f1e801ec700: Action 0x773f30 transitioned to state: susp
                              >> 6549.950424235:7f1e801ec700: earliest retry=1405626579
                              >> 6549.950547990:7f1e801ec700: actionTryResume: action 0x773f30 state: susp, next retry (if applicable): 1405626579
                              >> [now 1405626549]
                              >> 6549.950670278:7f1e801ec700: action 0x773f30 call returned -2123
                              >> 6549.950791526:7f1e801ec700: tryDoAction: unexpected error code -2123[nElem 1, Commited UpTo 0], finalizing
                              >> 6549.950918380:7f1e801ec700: actionTryResume: action 0x773f30 state: susp, next retry (if applicable): 1405626579
                              >> [now 1405626549]
                              >> 6549.951047467:7f1e801ec700: ruleset: get iRet 0 from rule.ProcessMsg()
                              >> 6549.951176003:7f1e801ec700: ruleset.ProcessMsg() returns 0
                              >> 6549.951304871:7f1e801ec700: regular consumer finished, iret=0, szlog 2 sz phys 3
                              >> 6549.951450891:7f1e801ec700: we deleted 1 objects and enqueued 0 objects
                              >> 6549.951581801:7f1e801ec700: delete batch from store, new sizes: log 2, phys 2
                              >> 6549.951714407:7f1e801ec700: processBatch: batch of 2 elements must be processed
                              >> 6549.951842101:7f1e801ec700: Processing next rule
                              >> 6549.951976131:7f1e801ec700: testing filter, f_pmask 255
                              >> 6549.952129821:7f1e801ec700: testing filter, f_pmask 255
                              >> 6549.952262169:7f1e801ec700: Processing next action
                              >> 6549.952391831:7f1e801ec700: Called action(NotAllMark), processing batch[0] via 'builtin-file'
                              >> 6549.952519223:7f1e801ec700: Called action(NotAllMark), processing batch[1] via 'builtin-file'
                              >> 6549.952646815:7f1e801ec700: Called action(Batch), logging to builtin-file
                              >> 6549.952783805:7f1e801ec700: XXXXX: tryDoAction 0x7677e0, pnElem 2, nElem 2
                              >
                              > *via www.LinuxMint.com 16:Petra*
                              > Am 17.07.2014 21:36, schrieb Wietse Venema:
                              >> XYZFounder:
                              >>> Hi Wietse Venema:
                              >>>
                              >>> I get output in the logs but nothing (no error) why it is held (still)
                              >>> in the queue. BTW Could one somehow bad email holt up the entire queue?!
                              >> You have too much noise in the mail.log file.
                              >>
                              >> Remove all the -v options from master.cf, do "postfix reload",
                              >> "postfix flush", and wait for a few minutes. If the logging does
                              >> not explain what is wrong, you can come back
                            • Wietse Venema
                              ... That is not Postfix. Can you get rid of this? Wietse
                              Message 14 of 16 , Jul 17, 2014
                              • 0 Attachment
                                XYZFounder:
                                > > 6549.948631801:7f1e801ec700: pipe (3) write error 11: Resource
                                > > temporarily unavailable
                                > > 6549.948709925:7f1e801ec700: Action 0x773f30 transitioned to state: rtry
                                > > 6549.948786551:7f1e801ec700: action 0x773f30 call returned -2007
                                > > 6549.948861671:7f1e801ec700: tryDoAction: unexpected error code

                                That is not Postfix. Can you get rid of this?

                                Wietse
                              • XYZFounder
                                Yes, it was the virtual modul. after reboot the old dating from July 14th finally could be removed (ps aux | grep virtual) and now all is set and in the log
                                Message 15 of 16 , Jul 17, 2014
                                • 0 Attachment

                                  Yes, it was the virtual modul. after reboot the old dating from July 14th finally could be removed (ps aux | grep virtual) and now all is set and in the log postfix uses relay= virtual and my
                                  mailboxes are filled again!

                                  THX for your time Wietse Venema.

                                  J


                                  via www.LinuxMint.com 16:Petra
                                  Am 17.07.2014 21:36, schrieb Wietse Venema:
                                  XYZFounder:
                                  
                                  Hi Wietse Venema:
                                  
                                  I get output in the logs but nothing (no error) why it is held (still)
                                  in the queue. BTW Could one somehow bad email holt up the entire queue?!
                                  
                                  You have too much noise in the mail.log file.
                                  
                                  Remove all the -v options from master.cf, do "postfix reload",
                                  "postfix flush", and wait for a few minutes. If the logging does
                                  not explain what is wrong, you can come back.
                                  
                                  	Wietse
                                  

                                • XYZFounder
                                  hm?! it was in the mail.XXX log. Anyhow, as written: solved THX again 4 ur time. J *via www.LinuxMint.com 16:Petra*
                                  Message 16 of 16 , Jul 17, 2014
                                  • 0 Attachment
                                    hm?! it was in the mail.XXX log.
                                    Anyhow, as written: solved

                                    THX again 4 ur time.

                                    J


                                    via www.LinuxMint.com 16:Petra
                                    Am 17.07.2014 22:12, schrieb Wietse Venema:
                                    XYZFounder:
                                    
                                    6549.948631801:7f1e801ec700: pipe (3) write error 11: Resource
                                    temporarily unavailable
                                    6549.948709925:7f1e801ec700: Action 0x773f30 transitioned to state: rtry
                                    6549.948786551:7f1e801ec700: action 0x773f30 call returned -2007
                                    6549.948861671:7f1e801ec700: tryDoAction: unexpected error code
                                    
                                    That is not Postfix. Can you get rid of this?
                                    
                                    	Wietse
                                    

                                  Your message has been successfully submitted and would be delivered to recipients shortly.