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)

  • RBGE replied to this.
  • 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 πŸ™‚

    Bedarbis The first cron job appears to be correct - it's telling php to run the cron.php file, whereas the second one is telling php to run php.
    The server info page says you're running PHP 8.1 - and yes, while upgrading osTicket to 1.18.1 won't fix this particular issue, it's still worth doing πŸ€“

      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.

      • RBGE replied to this.

        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

          Bedarbis There is no user in the cron job, this is the crontab for user 'apache' (sudo crontab -l -u apache) which is the user accessing the osTicket files on my server

            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 πŸ™‚

              Bedarbis

              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.

              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

              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 πŸ™‚

                Bedarbis

                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.

                  Write a Reply...