Hello. My cron job stopped working when i updated my xubuntu linux (does not send a reply to the user that support received their email (other than that it looks like its working fine). I was using php 8.1 but it looks like 8.2 is now installed. This is how my cron job looked like when it was working.
I thought that maybe the path to php is wrong but it did not helped
This is current running server info
And this is to show that auto-fetch is on
.
Can anyone help me with what i am suppose to do? Update php modules to 8.2, or maybe revert to php8.1, or update osticket to 18.1 (i doubt that this would help with my problem here)
Cron stopped working after I update/upgrade my Xubuntu Linux server
RBGE well yes when i configured osTicket i configured it to work with php 8.1 and it was running really good. I was really happy with it. But then dumb idea came to my mind to update my server since it wasnt updated for a year or so and then that happened. I thought that it might have updated php to 8.2 version but when i use command "php --version" terminal returns that my php version is "8.1.28" so i am kinda out of ideas.
Bedarbis Upgrading the server isn't a dumb idea... it gets a lot more difficult to move to supported versions when you start using EoL stuff.
As for the cron job, does the user running the task have access to the /home/rat/ directory? (and the /var/www/html one as well, of course!)
Here's mine, which is working perfectly after numerous server upgrades over the years:
*/2 * * * * php /var/www/html/api/cron.php > /dev/null 2>&1
RBGE well i have 2 users "rat" is the main one and other one is www-data. If i write crontab -e as "rat" user it opens crontab with cronjob */2 * * * * php /var/www/osTicket/upload/api/cron.php > /home/rat/cron.log 2>&1 (the one i posted in the first post). So i presume "rat" is the one who does the cronjob (i should really document stuff next time). When it comes to /var/www/osTicket (in my case) ls -l shows www-data as the owner but then "rat" have sudo privileges so it shouldnt be a problem (as far as i know). Please tell me if i am talking rubish 
i have some Linux experience but not much 
- Edited
I would simply try commenting out the crontab entry for "rat" and move it to the www-data crontab and retest. You should also try to get the full path (or alias) for PHP 8.2 and use that instead of "php". Most linux distros that allow multiple PHP installations typically have the main on as "php" and the rest with version specific aliases like "php81" or "php8.1". When in doubt, consult the almighty google for guides/instructions on your specific distro, the php repo you used to install php (like remi, ondrej, sury, etc.), etc.
If you truly want the "rat" user then it'd probably be better to add "rat" to the "www-data" group so it can access files owned by that group.
Cheers.
- Edited
Bedarbis I'd advise not running cron jobs as a user with sudo access, mainly for security reasons. In this case, the php command is not being run with sudo anyway, so it makes no difference whether the account has privileges or not.
While I don't see a reason why this is suddenly not working, it's possible there may be some permissions issue running the cron.php file (remember, "rat" may have sudo privs, but isn't using them in this cron job).
Do you need to keep the log outputs from the cron job? That /home/rat/cron.log file must be getting quite chunky.
If not, I'd suggest going with Kevin's suggestion of commenting out (or removing) the rat cron job, and setting up a new one as www-data
sudo crontab -e -u www-data
Then enter the following
*/2 * * * * php /var/www/osTicket/upload/api/cron.php > /dev/null 2>&1
Save and quit.
Whether or not you use the full path is up to you - my advice is to use the global php as then you don't have to keep updating the cron job every time you update PHP. If you have more than one version and want to force using a specific one, you can use the alternatives command. If there are multiple tasks this server is used for, then you can always fully specify the path - just remember to update the cron job when you update the server.
Once it's all working, set a maintenance schedule to apply regular updates to the server 
Edit: Just to add, if you suspect it is a permissions issue, do not change the owner of all the web files to rat - that'll break a lot more than it fixes!
6 days later
- Best Answerset by KevinTheJedi
Ok I managed to solved it. The problem wasnt www-data or rat user cronjobs. They were working fine, the problem was (as far as I can tell) PHP modules. I updated my server apache to use PHP8.3 and then installed 8.3 PHP modules (but i still do not know which module in particular made this thing work) and it looks like it's working as intended. Thank you for your help
Be careful, 8.3 is not fully supported yet so you may run into issues. It’s always a good idea to look at the version requirements before upgrading them.
Cheers.
KevinTheJedi ok i will have this in mind. Even failed attempt is still better than none. Its always a learning process for me.