External cron polling not working after upgrade

jfried

Updated to 1.17 and set our PHP version to 8.0.25

-SMTP works
-IMAP polling no longer works (previously configured as an external cron job)
-Enabled auto-cron for imap polling and that works (only when we are logged in of course) so the imap credentials are good.

I reached out to the hosting company who sent me a screenshot confirming the cron job was running as scheduled. There are no errors they can see on their end. Is there a known issue with this version of PHP and the /api/cron.php script?

KevinTheJedi

jfried

Nope. You’ll just have to debug and see what’s going on. I cannot replicate this. Make sure the cron is running the correct PHP version.

Cheers.

jfried

KevinTheJedi With OSTicket 1.17 should cron be using PHP version 8.0.25 or an older version of PHP?

mfahad1

Same thing happening here. SMTP works, IMAP works with O365 OAuth. Cron jobs successfully running. Mails not being fetched.

No errors or warning on the admin panel dashboard.

KevinTheJedi

mfahad1

Are they being marked as Read? You say "cron jobs successfully running" but have you set your log level in osTicket to DEBUG and look at your system logs to see successful "cron job executed" messages? Or you are just assuming?

Cheers.

mfahad1

Hi Kevin, emails are not being marked as read.

I check the cron jobs execution through the cpanel back end, they create a system log each time the cron job runs, i.e. every 5 mins. Not assuming.

This is the same place I received the error when I was on 1.17, then updated to 1.17.x and the cron job started successfully running.

mfahad1

Further findings:
When I login and set the oauth token through o365, the system starts fetching emails, once that token expires and renews itself, the emails stop fetching. So the problem seems to be when the oauth token renews

KevinTheJedi

jfried

It can be running PHP 8.0 or 8.1. Ideally you'd want it running the same PHP version as the website for continuity reasons but as long as it's 8.0 or 8.1 you should be fine.

That is strange. You can login to your database, go to the email_account table, look at the auth info for the email in question, and see if you see a last_error_message value.

Cheers.

jfried

KevinTheJedi thanks for info. I ended up applying 1.17.x from the repo to resolve the double header issue and after toggling mail-fetch off then on again all is working as expected. Thank you!

mfahad1

I fixed the issue I was facing by using the PHP 8.1 in cron jobs. Previously the system was by default using PHP 7.4 to execute the cron jobs.