I have a simple PHP script that I created to do some basic maintenance on my DynamoDB account and I would like it to run daily. I have it set up on my host which is GoDaddy Windows based / plesk. When I go directly to the page via a browser it runs perfectly and does exactly what I want. However I set it up as a scheduled task and I get this error every time it runs:
Status: 500 Internal Server Error
Content-type: text/html
PHP Parse error: syntax error, unexpected '$value' (T_VARIABLE) in **path removed**\AWS\Aws\functions.php on line 36
I have googled and have found tons of sites with this error but they all say that it was related to the PHP version being earlier than 5.5 and PHP 5.5 minimum is required. However I am running PHP 5.6, plus like I said it runs fine if I just go through a browser, it's the scheduled task that doesn't work...
I'm guessing there is something different about the way a task is pathed or run or something but I can't figure out what it is, does anyone have any insight?
Well technically the error being thrown is the 'unexpected T_VARIABLE' error referenced at Reference - What does this error mean in PHP?, that's not really the issue. That php file is inside the AWS SDK so I don't think the answer is that it's coded wrong. Also it runs on a normal page, just not in task scheduler so really the question is what am I doing wrong with task scheduler that is making it error out...
Ok I'm dumb, I knew it would be something simple. In case anyone has the same issue, the path I put for the php executable in task scheduler was the one for PHP 5.4, not 5.6. I had my hosting set for PHP 5.6 but was telling task scheduler to run PHP 5.4 hence the error. Updated the exe path and it works now.
Related
Recently we updated our server from PHP version 5.6 to PHP 7.4, since this upgrade we are experiencing some very strange behaviour of some scripts.
The script themselves are fully PHP 7 suitable, there are no error logs or what so ever being printed or even logged when the problem occurs.
What happens is follows:
A script is started, this script calls several functions, when 1 function simply takes to long to finish then the main script stops, there is no error or output given what indicates that something is or went wrong.
It does not matter if we run this script by a GUI or via CLI, on both the result is the same.
The script stops/breaks (on cli you are back on prompt) every time when a called function (does not matter what function) simply takes to long to finish, as mentioned the cause is NOT a php code error, the code is valid.
When the same script is ran using php 5.6 then the script keeps waiting until the called function is finished and then normally continues as it supposed to.
It looks like there is a (new) setting somewhere in PHP7 which limits the execution time that a called function may run otherwise I cannot explain this behaviour, the problem here is which setting is this exactly and how do I change it, the obvious settings we already changed.
Has someone an idea where to look or search for these kind of settings?
The system is running on Centos 8 and using PHP 7.4.13 (or php 5.6), when using an older PHP version (7.2) the problem is the same, only php 5.6 does not have this problem at all.
Error reporting is turned on, no errors are logged whatsoever. If we run a script on PHP 7.4. The script stops from CLI after a short period (1 - 2 minutes). When running the same script on PHP 5.6 it runs for a long time (which it should in this case). Our developpers found that a function that calls another function to check whether an email account exists (HELO check) takes longer than 2-3 seconds, the entire PHP script is stopped in 7.4 where PHP 5.6 just waits longer and runs the entire script
last year i have purchased an encrypted script wich run two crons jobs, a month ago crons stop working and i have talk to the hosting company they said its script problem , The PHP cron file works fine without any errors when visited by browser, the script provider told me that this issue should be fixed by hosting service and refuse to help !
here the command used it run every 10 MIN /home/username/public_html/cron/cron.php
cPanel Version 64.0 (build 24)
Apache Version 2.4.25
PHP Version 5.6.30
my question is it true upgrading the PHP version will affect cron job and how can i solve this?
thanx
In short, yes, upgrading PHP can effect your scripts -- the crons aren't run by Apache or PHP; the crons run from the OS level.
Your PHP upgrade is most likely affecting the crons in one of two ways:
The upgrade was large, like PHP5.6 to PHP7.0 and there's a deprecation warning somewhere (which will output in the crons' log) or the script is running some code that's now fully deprecated; most likely a query or a class/method named after a reserved word. Your logs will have more info, just make sure you have debugging turned on, otherwise your errors will be suppressed.
The new PHP settings from the upgrade have disabled some of the allowed rules from an older PHP version, such as getting away with empty or unassigned variables, and now your script is running into errors (ie. using a variable that doesn't exist, such as $_REQUEST['something'], which would have been empty but now returns an error that effects the rest of the script).
To fix this you need to know what the problem is. The easiest way is to access the log files that crons often create. If you don't get that with your host, ask them for it, or ask them to send you a copy of the error that's being created -- a quick Google on the error will tell you what the problem is. But without knowing more about the script or the error log, you probably won't get a better answer.
old command is working its just me i did copy past from my old backup and i forget the PHP at the firts off command ! nothing has changed the command should be like that exp : php /home/username/public_html/cron/cron.php
I have a php script that connects to a database to run a query. This works fine when running the script by browsing to it. The problem I have is when I use the Task Scheduler within the Synology server's control panel. For some reason I am getting the following error:
PHP Fatal error: Call to undefined function mysqli_connect() in /volume1/web/bimotech/check_ip.php on line 13
As mentioned, this works fine when running from the browser but not when scheduled.
Any ideas?
Thanks,
John
It sounds as though the PHP you're running was built without mysqli, or perhaps mysqli is not loaded. Can you run a phpinfo(); and make sure you have mysqli?
Bear in mind that the PHP you use in a CRON job can be different from the PHP that gets run by Apache when your web page executes.
You have to define the full path of your php, synology maybe using different version of php.
For example your php executable is installed on /usr/bin/php
you have to do something like
/usr/bin/php /path/to/script.php
I am having a very hard problem to solve, which is that my symfony application server terminates and never loads anything. The message is giving after running the: php bin/console server:run and then load the site in the browser. The browser starts loading the site but after a few minutes it throws this message in the console (not in the web browser): [ERROR] Built-in server terminated unexpectedly. Run the command again with -v option for more details..
I have tried to solve this problem in many ways:
Changed my OS to Windows (I am using Ubuntu 16.04). This did not work, the application just throw a blank page in the browser with not even one error.
Cleared cache.
Changed default port.
Please if any person has been involved in this situation and has left alive from it, help me out, I will appreciate it a lot...
I already solved the problem. I upgraded from php 7.0 to php 7.1, it is a bug of php I guess, I can't have any certain conclusion about what the problem was, but this solved it.
OS: Windows 8.1
Laravel-version: 5.3.15
Hello,
I'm having a bit of trouble getting Laravel's scheduler to properly run on on my machine and STAY RUNNING in a way where I can see some sort of output to indicate that it's actually working. Every time I run php artisan schedule:run it calls any listed commands once and then just dies. It doesn't repeat or anything. Example attempt below:
The Code:
The Result When Trying to Run the Scheduler:
What I've tried:
I've tried multiple suggested fixes from the link below and some are actually referenced throughout stackoverflow as well. Including adding a batch file, setting php's path in my system veriables etc etc. as suggested in the link below by Kryptonit3:
https://laracasts.com/discuss/channels/general-discussion/running-schedulerun-on-windows
However, nothing works. Even in the "Windows Task Scheduler" tool it will just run once, end any further processing in the CLI and then close the window. There is no actual indication that this scheduler is running in the background indefinitely (Sort-of like a background job only without the queues).
Questions:
1 - With no indication (the echoed "I am Scheduled") how do I know if this is actually working?
2 - Why does attempting to run this command die after it successfully completes once.
3 - Does my Laravel Version have anything to do the scheduler not running permenently when I try using php artisan schedule:run in the CLI or windows task scheduler?
4 - Mainly what I'm trying to accomplish here is every minute the system would scan a single DB table's field. How do I accomplish this?
5 - Can someone please give me some clarification on this? Or point me in the right direction so that I can get this thing really running indefinitely without it just ending after the first run?
Note: I do not want to use Laravel Forge or any other external service for something so simple. That would be overkill and unecessary I feel.
after doing some rather serious digging I found that all of what Kryptonit3 had said in his step by step answer that I referenced was correct. However, I did not know I needed to restart my computer after creating a new task with the Windows Task Scheduler. I thought this would happen automatically. Would've saved me 2 days of debugging had I'd of known but regardless, if someone else comes across this similar problem they will know to reboot the computer.
Reference:
https://laracasts.com/discuss/channels/general-discussion/running-schedulerun-on-windows