Email polling/fetching not working in v1.18.2

ealtman

I moved a v1.17.5 to a new server (same Oracle Linux 9 instead of Redhat 8) and upgraded to v1.18.2.
I used plugins that were downloaded with the new package (don't know if there were updates) and followed all the recommended update steps.
I updated the Helpdesk URL.
Got a new OAUTH2 connection from my Azure manager
I reconfigured the endpoints for the OAUTH connections in the system email to match the site, and configured with a new secret and id, and the connections test out fine.

When I create a ticket in the console, it emails out to the relevant staff as expected. However, it is not polling or fetching email.

I seem to have been able to effect polling on the previous server without a crontab entry, but I really don't know how that worked.

On the new server, I created a crontab entry, with the user that owns the cron.php file, in this case apache. But this had no effect.

What environmental factors am I missing?

KevinTheJedi

ealtman

Couple of things to verify:

When you go to the email’s Remote Mailbox tab and click Config next to Authentication, do you see a Token tab? If not you did not receive a token successfully and need to reattempt the authorization.
Within that same Remote Mailbox tab is the Status set to Enable?
With the Status set to Enable can you Save Changes successfully?
Do you have fetching enabled globally? Admin Panel > Emails > Settings > Enable Fetching (only use the Enable option; not the auto-cron option)
What does your cron job look like? You can verify it is executing successfully by setting your Default Log Level (Admin Panel > Settings > System > Default Log Level) to DEBUG, let the cron run a few times, and check your system Logs (Admin Panel > Dashboard > System Logs) for an entry stating the Cron job executed. If you do not see such an entry then it’s not actually running correctly.

Cheers.

ealtman

Yes to the token and settings and save changes questions.

So, to the cron task - no there are no OSTicket cron log entries on the new server.

I was wrong about there not being a cron task on the older install (on the other server) - but I'd done it in a sort of harebrained way, setting up the task in a user-based crontab, so it was harder to track down. Thanks for making me chase the logs (duh).
I had the incorrect php path on the new server, so I fixed that, and I used the same user as on the old server (but a global cron).
In any case, /var/log/cron shows it's cooking away, but no cron entries are present in OSTicket. Statement looks like this:
*/5 * * * * [non-sudoer that owns osticket] /usr/bin/php /var/www/html/web/api/cron.php

KevinTheJedi

ealtman

Try logging in as the user you are using for the cron and run the cron command manually via cli and see if that works. You can also try changing it to the root user and see. It may be a permissions issue.

Cheers.

ealtman

I feel like deleting this entire question because it turned out to be COMPLETE SYSADMIN ERROR.
Was able to run cron.php as root but not as the user, even when the user owned it. So I tried installing a user crontab as on the previous server, but that still had no effect. Turned out crond wasn't running. Don't even know how it occurred to me to check. Started and enabled daemon and now all is well. I'm not sure why/how I thought the logs showed it running before. Maybe it was all the testing. Thank you for your patience.