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
