Command time limit exceeded: "/usr/bin/procmail"

[Hajo Locke]

Hallo,

wir kennen ähnliches, verursacht durch POP-User. Vergleich mal die 
login/logout Zeiten bei den betroffenen Usern, wenn diese per pop 
zugreifen.  Wenn da viele Minuten dazwischen liegen, sendet der User 
vermutlich kein korrektes logout, meist ausgelöst durch Firewall oder 
Virenwächter. Solange dovecot das Postfach für aktiv hält, gibt er es 
nicht frei (pop=exclusiv) und procmail kann wegen des lock nicht 
zustellen. Womöglich war euer command_time_limit vorher kürzer als das 
dovecot Inaktivitätslimit (30 min?).
In der Richtung könnte man mal forschen.

Hajo

Am 22.08.2016 um 13:27 schrieb Christian Schoepplein:
> Hi zusammen,
>
> auf einem System, auf dem via procmail einkommende Nachrichteng in ein
> OTRS gepiped werden und auf dem die Mailzustellung grundsätzlich
> funktioniert, bekommen wir ab und an mal folgenden Fehler:
>
>      Command time limit exceeded: "/usr/bin/procmail"
>
> In main.cf steht command_time_limit auf 2000s, was ja eh schon Wahnsinn
> ist, aber an welcher Schraube könnten wir ggf. denn noch drehen, um den
> obigen Fehler zu beseitigen?
>
> Hier mal die .procmailrc des lokalen Users, über den die Zustellung
> läuft:
>
> -----
> SYS_HOME=$HOME
> SHELL=/bin/sh
> PATH=/bin:/usr/bin:/usr/local/bin
> DAYFOLDER=`date +%F`
> LOGFILE=$SYS_HOME/var/log/procmail-$DAYFOLDER.log
> VERBOSE=on
>
> # Pipe all email into the PostMaster process.
>
> :0 :
> | $SYS_HOME/bin/otrs.Console.pl Maint::PostMaster::Read
>
>
> # spool all the rest (which the otrs.PostMaster.pl can't process!)
> # If the database is down or the otrs.PostMaster.pl exit was not '0'!
>
> :0 :
> $SYS_HOME/var/spool/.
> -----
>
> Ciao und danke für jeden Hinweis,
>
>    Schöpp
>
>
>