OpenEMM Technical Support Forum

The var/spool/QUEUE directory had over 10k files in it and didn't accept any new files:
Only after a restart of OpenEMM things went on normally and mails from the queue were proccessed and new were accepted to the queue with the queue growing up to 15k.

As a workaround, which processes do need to be restarted periodically to avoid such a lock?

Is this a known issue? OpenEMM 6.0.1 is being used.

A restart only leads to the unpacking of the next chunk of 5,000 mails, so it does not help really. You have to investigate why Sendmail can not empty its queue: Are receiving SMTP servers blocking mails? Too many invalid addresses or softbounces?

ma wrote:A restart only leads to the unpacking of the next chunk of 5,000 mails, so it does not help really. You have to investigate why Sendmail can not empty its queue: Are receiving SMTP servers blocking mails? Too many invalid addresses or softbounces?

Thank you for your reply. We're not using sendmail but OpenEMM's semu.py (I guess it stands for Sendmail emulation ).

I don't know why this happened. From what I understand there was no machine or network failure, so I suppose it was some kind of a software hiccup.

After the restart, the queue got down to 2k after accepting and delivering another chunks in a total of ~ 50k, so I am happy with the result, but we need to avoid such a lock where mail is not delivered and incoming new mailings are blocked by a filled up queue as recipients get easily upset when the recieve several mails in a short time span which were meant for daily delivery.

I suppose it is okay to restart "bounce.sh, merger.sh, mailer.sh, slrtscn.sh" and leave "core.sh" with Resin running? For a confirmation on this and any further hints I'd be very grateful.

Yes, the backend scripts and the Java frontend work independently and communicate via the database.

Thank you.