Can process queue manually / Can't process queue via cron job

I’ve been running PHP List for a couple years–always processing the queue via cron jobs.

After a server update and switching from PHP 7.3 to 7.4, I can’t process the queue via cron jobs anymore.

Here’s what I’ve tested:

*Processing the queue manually works
*The embargo period in the scheduling section is fine–as it begins at the top of the current hour
*The cron job is the same as before the updates
*The cron job is running correctly after the updates

Any idea what I can do to get the queue processed via cron jobs again?

@chriscasemart It is not very clear what is not working.

Look at the Event Log page for any errors being reported.
In the command to run processqueue capture the output to a file so that you can see any problems with the command.

Sorry if my note was unclear.

When I wrote “the cron job is running correctly” I meant that the cron job runs regularly. It just doesn’t prompt the queue to process.

I checked the error log, and here’s what it says after the cron runs:

(No MTA installed, discarding output)

Per my original note, the queue is processed correctly when I run it manually from the Process Queue button. So, the issue seems specific to the cron–rather than a MTA or lack of MTA.

As context, here’s the cron–with my server details replaced by xxx:

/usr/bin/php /home/xxx/public/lists/admin/index.php -pprocessqueue -c /home/xxx/public/lists/config/config.php

And the messages are handed off to Amazon SES for delivery, if that matters.

Does there appear to be an issue with the cron? Or should I be looking elsewhere?

@chriscasemart I referred to the phplist Event Log page to see any problems reported by phplist. That will also show whether phplist found any campaigns to process.

And capture the output of the cron job to a file, add this to the end of the command to capture the output to a file processqueue.log in the current directory

>processqueue.log 2>&1

With regard to the Event Log page, I installed the addons plugin and exported the Event Log using that.

Is that the log data to which you’re referring?

@chriscasemart Just look at the Event Log to see if there are any problems reported. I don’t particularly want to see it.

What about the output of the cron job?

The exported event log doesn’t show any activity at all for today–so none of today’s cron jobs are reflected there. The last activity was from yesterday when I processed the queue manually.

As for the cron job, I added >processqueue.log 2>&1 and the cron has run again with that included, but I’m not sure which would be the current directory.

I looked in all three directories referenced in the cron:


But, I didn’t find a filed called processqueue.log in any of the three.

Is there somewhere else I should look?

@chriscasemart Probably the “home” directory /home/xxx
Otherwise add a path to the file name.

I added a path and found the file.

Here are the contents:

The following PHP extensions are missing:

Do you know why the manual Process Queue option would work correctly without these extensions but the cron job won’t process the queue without them?

Partly, I’m curious. But, on a practical note, I’m trying to understand if this is actually the issue–before I add the extensions–so I’m not layering new variables into the issue.

@chriscasemart php run from a cron job or command line is a different program to that run by the web server. It is usually referred to as php-cli. You do need to enable those php extensions for the command line php, they must already be enabled for the web server php.

This issue is resolved, and I’ve written up some notes on what worked and how I got there–in case anyone else finds themselves in the same jam.

Picking up from the reply above, I tried to install the three PHP extensions, but they were already there in PHP 7.4.

It turns out the issue is that my server is running PHP 8.1 as well and treats that as the default.

So, I was able to get the cron job to refer to the 7.4 version by using usr/bin/php7.4 instead of /usr/bin/php in the cron job itself.

When I run the updated cron job, I still get the error message that there’s no MTA.

But, the messages are sent out correctly in spite of this error message.

I suspect this is because I’m sending via Amazon SES using SMTP instead of sending from the server itself.

Either way, the cron job is once again processing my queue. And, these are the changes that got it back on track.

Thank you, duncanc, for sticking with me as I worked through this.

I wasn’t getting anywhere on my own, so I really appreciate your suggestions and time.