Mautic Community Forums

Emails Stuck in Que

Your software
My Mautic version is: 4.15
My PHP version is: 7.4.23
My Database type and version is: 10.5.12-MariaDB-1:10.5.12+maria~bionic

Your problem
Emails were sending fine but yesterday when testing a segment email, the email is getting stuck in que.
Screenshot: Emails _ Mautic - Google Ch...

Any help would be appreciated.

2 Likes

Hi can you check the logs inside mautic/var/logs folder.

Maybe that will give us more info and we can debug it further.

Sure. Can you please tell us exactly what you need from those logs and we can post here.

When you are sending emails and if things stop (as it appears in your case) is usually because something is failing / has failed. More info about why some things failed might be available in the log (I do not know the error yet).

Try to trigger mautic cronjobs manually while monitoring the mautic logs and see if anything is shown. Make sure there are not any sensitive info in the logs before you post it to public forum.

I ran into the same issue today. Been sending emails all week now all of the sudden messages are stuck in a pending state.

When I run mautic:broadcasts:send from the command line I get the following…

PHP Warning: fopen(/opt/bitnami/mautic/var/cache/prod/…/run/sf.mautic-broadcasts-sendall.716fb070e0a1b27203408f49f68f94a8ef8bed583888fb213b8b98e48503cf7c.lock): failed to open stream: Permission denied in /opt/bitnami/mautic/app/bundles/CoreBundle/Command/ModeratedCommand.php on line 151
PHP Warning: flock() expects parameter 1 to be resource, bool given in /opt/bitnami/mautic/app/bundles/CoreBundle/Command/ModeratedCommand.php on line 152
Failed to lock /opt/bitnami/mautic/var/cache/prod/…/run/sf.mautic-broadcasts-sendall.716fb070e0a1b27203408f49f68f94a8ef8bed583888fb213b8b98e48503cf7c.lock.
Script in progress. Can force execution by using --bypass-locking.

I guess maybe that’s an accurate/ok message in the sense that maybe something is currently running and it’s correct that that lockfile is there? I can also see the same (mautic:broadcasts:send) command and others getting fired off from cron in the syslog. Maybe clear the cache? That seems to be the magic elixer for many Mautic issues. Thoughts?

Sorry, realized I needed to run as root, like the cronjob itself. doh!

Anyway, for me it appears to be a different error. I am sending to a fairly large segment (65k). Getting the following errors.

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /opt/bitnami/mautic/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php on line 255
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32768 bytes) in /opt/bitnami/mautic/vendor/symfony/error-handler/Error/OutOfMemoryError.php on line 1

Know of anything I can do about that?

I changed the memory_limit in php.ini but it’s not being reflected in on the Mautic system info page. Any idea why that would be?

  • In regards to memory_limit be sure to restart php service.
  • But I think you should set limit on number of items in Que.
  • Also running cron jobs as root might not be such a good idea since ti might cause permission issues

Thanks for the reply! I really appreciate the feedback.

I set the memory_limit to1024M. I did NOT restart any services that use PHP because it seems all I need that much memory for is the cron jobs. If any of the services that use PHP (apache, phpmyadmin …) do restart for whatever reason it should be fine, I have a fairly beefy server running 32 GB of RAM and 8 cores on AWS.

When you say “limit the number of items in the queue” I assume you’re referring to the --batch=x, --limit=x and min/max id options? I’ve looked at those but honestly, the Mautic docs on those are a little confusing.

I actually use sudo and not root. Otherwise it would not run and I’d get permission denied errors.

I don’t know if this is appropriate or allowed here? But would you be available for a little bit of private consulting on some of this Mautic stuff?

In order for changes in php config to take affect you should restart your php services or web server (like apache or whatever you are using - it depends on how your server is setup).

About the limit options… yes, also you might have to look into options in email settings:

I can offer my help, drop me a message to: matic@sos-sw.si if interested.

Regards, M.

I don’t think you should have to restart anything in order for the cron jobs to use the new memory_limit setting because they effectively restart every time they run, I’m pretty sure it’s not like the cron daemon itself is using PHP.

Yep, I’m aware of and have set those email settings, although I may still have them set a little aggressively. It doesn’t appear to be the actual email delivery that was my issue. It seems to have been the processing of the “broadcast” emails into the mail queue that was causing the memory issue. I’m imagining the mautic:broadcasts:send command trying to gulp 10s of thousands of records out of the database to put them in the mail queue.

Those cron jobs you run are actually php scripts.

I understand the cron jobs are PHP scripts but they’re not persistent processes. Every time the cron daemon fires off one of those PHP scripts it’s firing off a new process from scratch so there’s nothing to restart in this context. What would there even be to restart? Of course, if I wanted Apache to pick up the new memory setting I’d have to restart it. It seems to have worked. Am I missing something?

I do not know the specifics of your server. You can create the script that display php setting and run it in terminal to check what the value of memory limit is.

There is a high posibility that vore of the issue lays in something else.

php -i | grep memory_limit
memory_limit => 1024M => 1024M

Your issue is different then original poster. In his case the daily max limit was set as 0.

2 Likes

Yep, I ran into that issue already too. :wink: I think there was a long thread in Github or some such about that issue. Seems like Mautic setting the default on that to 0 was a bug in v3 or v4? Something like that.