brandoninsc Posted November 9, 2022 Posted November 9, 2022 I have tasks running via Cron Job, as the software recommends - however, for some reason, task.php is not running properly and gives message "not at command line". I have had my server support look at it and they tell me that the cron job is running properly, however, the task.php is not running as expected.  I have copied the exact command and copied it to my cron, running every minute - but I always get the same message "not at command line" I am running php version 8.2.0. Any ideas?
brandoninsc Posted November 9, 2022 Author Posted November 9, 2022 Specifically, here is what I get when the job runs: Cache-Control: no-cache, no-store, must-revalidate, max-age=0, s-maxage=0Expires: 0Content-type: text/html; charset=UTF-8Not at command line
Marc Posted November 9, 2022 Posted November 9, 2022 Have you ensured that the task.php file is executable?
brandoninsc Posted November 9, 2022 Author Posted November 9, 2022 Marc - thanks for the reply. Yes, the permission level is 755 and executable. Â
Jim M Posted November 9, 2022 Posted November 9, 2022 PHP 8.2 is not directly supported yet so I would recommend downgrading to PHP 8.1 or 8.0 first off. Second, could you please confirm that the command you are providing to CRON is that which is in ACP -> System -> Advanced Configuration? Ultimately, it sounds like the task is being executed as HTTP so would to ensure it is being ran via PHP in the command line.
brandoninsc Posted November 9, 2022 Author Posted November 9, 2022 Jim, downgraded to 8.1.12 and it didn't seem to make a difference.  I have this entered into the command field (site name was replaced by mywebsite). This is copied from the ACP. /usr/local/php81/bin/php -d memory_limit=-1 -d max_execution_time=0 /home/customer/www/mywebsite.com/public_html/applications/core/interface/task/task.php 1ff991c445e1dfacc7963576b00129b0
Jim M Posted November 9, 2022 Posted November 9, 2022 6 minutes ago, brandoninsc said: Jim, downgraded to 8.1.12 and it didn't seem to make a difference.  I have this entered into the command field (site name was replaced by mywebsite). This is copied from the ACP. /usr/local/php81/bin/php -d memory_limit=-1 -d max_execution_time=0 /home/customer/www/mywebsite.com/public_html/applications/core/interface/task/task.php 1ff991c445e1dfacc7963576b00129b0 When saving your setting in the ACP, are you getting any errors?
brandoninsc Posted November 9, 2022 Author Posted November 9, 2022 no errors. Just seeing that the tasks arent getting done, and ultimately getting the red error warning that it will eventually cause damage.Â
Jim M Posted November 9, 2022 Posted November 9, 2022 You would need to contact your hosting provider then to ensure you're setting this up correctly. Unfortunately, from our end, we have provided you with what the software would expect and function with. G17 Media 1
brandoninsc Posted November 9, 2022 Author Posted November 9, 2022 I was afraid it would come to that.  I only came to Invision on this issue once they told me that everything was set up properly on their end and I'd need to contact the developer.Â
Jim M Posted November 9, 2022 Posted November 9, 2022 9 minutes ago, brandoninsc said: I was afraid it would come to that.  I only came to Invision on this issue once they told me that everything was set up properly on their end and I'd need to contact the developer. Unfortunately, everything is executing properly on our end (you can actually run the command provided via SSH, if you access and it should render properly). This would, unfortunately, be a configuration error or issue with CRON if it is returning HTTP headers as it should be ran via PHP. G17 Media 1
lazzarus Posted January 21 Posted January 21 @brandoninsc, Not sure if you ever got to the bottom of this, but in case anyone else is looking - I just had the same issue running the cronjob with my hosting on Siteground and managed to find the solution with their support - the path to php (first bit of the cronjob) was different on the hosting than expected: /usr/local/bin/php82 NOT: /usr/local/php81/bin/php
teraĂźyte Posted January 21 Posted January 21 1 hour ago, lazzarus said: /usr/local/bin/php82 PHP 8.2 is not supported currently, though. If your site uses it, you should downgrade to PHP 8.1 instead. Otherwise, you might experience issues in some areas.
lazzarus Posted January 24 Posted January 24 On 1/21/2024 at 6:20 PM, teraĂźyte said: PHP 8.2 is not supported currently, though. If your site uses it, you should downgrade to PHP 8.1 instead. Otherwise, you might experience issues in some areas. Thanks. It is working absolutely fine and i like to be ahead of the game if I can be! I will downgrade if I experience issues.
Marc Posted January 25 Posted January 25 15 hours ago, lazzarus said: Thanks. It is working absolutely fine and i like to be ahead of the game if I can be! I will downgrade if I experience issues. For clarity here. It will break
lazzarus Posted January 30 Posted January 30 On 1/25/2024 at 10:23 AM, Marc Stridgen said: For clarity here. It will break Not broken yet....still on 8.2.
Jim M Posted January 30 Posted January 30 8 minutes ago, lazzarus said: Not broken yet....still on 8.2. You're more than welcome to run at whatever PHP version makes your heart content 🙂 . Keep in mind though, there are likely errors, just not in your every day actions. Keeping an eye on your error logs and keeping abreast to any missing users may help you determine this. A forewarning though, if you come forth with a support ticket, the solution is going to downgrade PHP 🙂 lazzarus 1
Recommended Posts