Auto-cron fetches emails but external cron job won't

rogerpenn

I have no hair left and my forehead is bloody...
When using "Fetch on auto-cron," emails are fetched and tickets created.
When using cron.php as a cron job (with 'Fetch on auto-cron turned off), email is not fetched, nor ticket created (obviously), but the job does run.
Here is my installation info:

Here is the syslog output when the cron job runs:
Jun 8 16:04:01 ro-helpdesk CRON[3230]: (root) CMD (su www-data -c "/usr/bin/php8.1 /var/www/html/osticket/api/cron.php")
Jun 8 16:04:01 ro-helpdesk systemd[1]: Created slice User Slice of UID 33.
Jun 8 16:04:01 ro-helpdesk systemd[1]: Starting User Runtime Directory /run/user/33...
Jun 8 16:04:01 ro-helpdesk systemd[1]: Finished User Runtime Directory /run/user/33.
Jun 8 16:04:01 ro-helpdesk systemd[1]: Starting User Manager for UID 33...
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Queued start job for default target Main User Target.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Created slice User Application Slice.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Reached target Paths.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Reached target Timers.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Starting D-Bus User Message Bus Socket...
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Listening on GnuPG network certificate management daemon.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Listening on GnuPG cryptographic agent and passphrase cache.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Listening on debconf communication socket.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Listening on REST API socket for snapd user session agent.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Listening on D-Bus User Message Bus Socket.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Reached target Sockets.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Reached target Basic System.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Reached target Main User Target.
Jun 8 16:04:01 ro-helpdesk systemd[3233]: Startup finished in 64ms.
Jun 8 16:04:01 ro-helpdesk systemd[1]: Started User Manager for UID 33.
Jun 8 16:04:01 ro-helpdesk systemd[1]: Started Session 75 of User www-data.
Jun 8 16:04:01 ro-helpdesk CRON[3229]: (CRON) info (No MTA installed, discarding output)
Jun 8 16:04:01 ro-helpdesk systemd[1]: session-75.scope: Deactivated successfully.
Jun 8 16:04:11 ro-helpdesk systemd[1]: Stopping User Manager for UID 33...
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Stopped target Main User Target.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Stopped target Basic System.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Stopped target Paths.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Stopped target Sockets.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Stopped target Timers.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Closed D-Bus User Message Bus Socket.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Closed GnuPG network certificate management daemon.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Closed GnuPG cryptographic agent and passphrase cache.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Closed debconf communication socket.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Closed REST API socket for snapd user session agent.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Removed slice User Application Slice.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Reached target Shutdown.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Finished Exit the Session.
Jun 8 16:04:11 ro-helpdesk systemd[3233]: Reached target Exit the Session.
Jun 8 16:04:11 ro-helpdesk systemd[1]: user@33.service: Deactivated successfully.
Jun 8 16:04:11 ro-helpdesk systemd[1]: Stopped User Manager for UID 33.
Jun 8 16:04:11 ro-helpdesk systemd[1]: Stopping User Runtime Directory /run/user/33...
Jun 8 16:04:11 ro-helpdesk systemd[1]: run-user-33.mount: Deactivated successfully.
Jun 8 16:04:11 ro-helpdesk systemd[1]: user-runtime-dir@33.service: Deactivated successfully.
Jun 8 16:04:11 ro-helpdesk systemd[1]: Stopped User Runtime Directory /run/user/33.
Jun 8 16:04:11 ro-helpdesk systemd[1]: Removed slice User Slice of UID 33.

Seriously hoping someone can tell me what I'm doing wrong! Thanks in advance.

KevinTheJedi

rogerpenn

What does your cron entry look like? What user is running the job? Does that user have appropriate permissions to access and execute the file? Have you checked your error logs for any related errors? You can verify cron execution by setting Admin Panel > Settings > System > Default Log Level to DEBUG, Save Changes, wait for the cron to run, go to Admin Panel > Dashboard > System Logs, and look for any Cron Job entries. If you don’t see one then cron is not running properly. If anything else went wrong you should see Mail Fetch logs or something else.

Cheers.

KevinTheJedi

rogerpenn

Maybe you just need to edit www-data's crontab directly using sudo crontab -e -u www-data?

Cheers.

rogerpenn

Thanks for helping. The Cron job and user are shown on the first line of the syslog output above. I already had switched logging to debug mode and entries are there. So it was running.

So here's something very weird. I just changed the cron job to run as a regular user rather than www-data, and it worked! Which makes no sense to me because all the examples and discussions I've seen to this point have been running it as www-data. My apache and entire /var/www/html (and everything underneath it, including /var/www/html/osticket/api/ ) is owned by www-data:www-data. Could it be because it has to run as a user with a shell login (www-data is /usr/sbin/nologin)? If that's the case, I would think that would be the same for everyone else as well. I also tried running it as root but that didn't work either.

So I guess this is resolved as far a my issue goes, in that I know how to make it work but I'd still appreciate if anyone has any insight into why it can run as an unprivileged user but not as www-data as everything suggests it should.

KevinTheJedi

rogerpenn

That I don't know, I'm able to run cron with my www-data user with no issues. Everything I've read online says as long as www-data has appropriate permissions on the files it should be able to run successfully. If you aren't getting any osTicket related errors then it seems to be system-level.

Cheers.

rogerpenn

KevinTheJedi Hmm. That had occurred to me, too. I'll give it a try and see what happens.

rogerpenn

That seems to have solved the problem. Adding the entry directly to www-data's crontab rather than running it as www-data from root's crontab works. Not sure WHY that makes a difference but it does. Thanks!

ntozier

Sounds like a permissions thing. 🙂