I'm trying to run a PHP script which has pg_connect($connection_string) and it just crashes my PHP script. I'm running it off of xampp on my computer, here are some facts:
If I put exit("test"); immediately above the pg_connect statement, it successfully displays the word "test" and terminates the script, so I know that my installation of xampp is working.
Using phpinfo() I can see that the postgresql extension is indeed loaded.
I can connect to the database server from pgadmin, so it's not a firewall issue or anything like that.
If I remove this exit statement, the pg_connect statement just hangs. There is no warning displayed or logged, and it never even gets past the function call. I even have:
$db_crm = pg_connect($connection_str);
if (!$db_crm) die("connection failed");
And "connection failed" is never even displayed. My browser just shows "this page cannot be displayed",after timing out.
What in the world could be causing this?
It's doubtful that the call is crashing PHP. More likely is that for some reason, the call is hanging for some reason and PHP's max execution time is being exceeded. You can try extending the time limit before making the pg_connect() call to see if it eventually comes back with something.
Check the Apache error logs
Check the php error logs
Make sure you have logging enabled in your Postgres config file.
In your config, set
log_min_error_statement (DEBUG5)
to grab everything possible.
Check the postgres error logs
Here it is guys:
I have no reason why, but adding sslmode=disable to the end of my connection string made it work. What reason would it have to crash? I am on a windows machine and phpinfo() says OpenSSL is enabled..
This sounds really stupid, but is your server running under SSL? I've had problems where a server will try to authenticate to ssl and hang indefinitely, trying to connect to a non-existent port.
sslmode=disable did the trick for me. To disable ssl in postgres-config ( ssl = false ) also worked.
For me, the Apache logs revealed that PHP was not finding the pg_connect() function, even though php-postgresql was installed. Restarting Apache fixed this, i.e.
sudo service httpd restart
Related
I can execute my php scrape file by typing in the address bar:
domain.com/scrape.php
However, I try to use cron job on my shared server on host gator by this command:
/usr/bin/php-cli public_html/scrape.php
I got this error message:
Fatal error: Call to undefined function GuzzleHttp\Handler\curl_reset() in /home4/username/public_html/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 78
I already update my php version to stable 5.6 or even 5.7 version also same error. I think that it should not be php version error because I still can execute the file from browser right ?
Also I cannot reboot server Apache because hostgator support said they cannot reboot it until the server is totally down...
Any help please ! Thank you !
I ran into this problem last week on my own server. As it turned out, my browser was looking at one installation of PHP and cron was looking at a 2nd installation of PHP. One way to check is to run a PHP script through your browser that executes phpinfo(). That will tell you what the browser is running. Have cron do the same and save the results. Compare the two and make sure they're pointing to the same installation of PHP. Don't just check versions. Check install paths and loaded modules. Cheers.
I'm using Apache for my localhost, bot now it's slowed down without any error suddenly, each time I start load a page it takes more than 1 minute , I do see any uncommon error in the error log , and my PHP code is also run perfectly without error.
I had tried several solution like adding localhost, enablemmap on off, setting only IPv4 but and non of it helping.
Is that anything more i can try to fix this ?
I fixed it by re-installing Apache server.
I am testing with MySQL on my home machine using an Apache server under XAMPP with the MySQL settings: Server: localhost via TCP/IP, version 5.5.16.
I have a query: SELECT * FROM project WHERE refno = $refno;
This works perfectly on my test machine. When I try the same thing on my ISP server, which has the following settings: Server: localhost via UNIX socket, version 5.0.92
I get the message:
"supplied argument is not a valid MySQL result resource"
Is the problem the difference in the settings? Is there anything I can do to get it working?
I would recommend you first make absolutely sure you have a valid database connection. Look for mysql_connect in your script, and make sure it is being passed the proper parameters. Look for the code examples on the man page to see how to add die() calls to catch any problems. Using die() is not a practice I would recommend on production code, though. You would usually want to catch and log errors, instead of having the script die.
Once you have made sure your connection returns a ressource, if it still chokes on you make sure you are sending the proper parameter (database name) to mysql_select_db.
Once these forementioned two functions play nice, your query should execute no problem.
Hope that helps, good-luck.
Just installed a nginx server with ubuntu 11.04 and after loading my php program i was writing i noticed that no MYSQL queries run. I get no errores, either from PHP nor MYSQL.
The user my PDO connection uses has all priviledges.
When i change the host to any value, i do not get any error either.
I believe mysql is not showing any connection error. How do i check it's enabled? Just checked mysql.conf and i see nothing related to error reporting. Also looked php.ini and all error options are enabled, i also enabled it in-code.
I have no clue, it's useless to work with no kind of error reporting!
Thanks!
Where are your error logs for nginx? Have you looked in those? Is mysql running? Try service mysql status. PHP should still give you an error though if it can't connect to the database. How do you know the queries are not running? What I mean is, what are the symptoms? Maybe the queries are running but your input is bad?
Most important is to try to isolate the problem. 1) Use curl -v http://your_server to make sure nginx is actually serving the pages. 2) Set up a phpinfo.php file in the root web directory with <? phpinfo(); ?> and check the mysql settings and verify where log files for php are being written 3) Try installing phpmyadmin and see if you can connect to the database using that.
Each one of the above eliminates at least 1 of the elements (your program, PHP, nginx, mysql), helping you to narrow down the cause of your problem.
EDIT: Additional instructions for item 2. You are looking for the php error_log setting. If it is not set, the errors should go to stderr, which in this case I think would be your nginx log files (true at least for apache). You could also check that error_reporting is set to some reasonable value (try error_reporting=E_ALL for now). You can set both of these in your php.ini file, or in your program. See the manual in section PHP Error Handling Runtime Configuration. I would do a sanity check by triggering an error in my program at the beginning of the program and making sure the error shows up in the log file:
trigger_error('Want to be a rock star test message', E_USER_WARNING);
If you see your message, you've got the right log file and you should find your other errors (if any - mysql might not be the problem, could be bad input as I mentioned before).
UPDATE (5/21/2010) SUCCESS!
So after MUCH $head->desk()'ing, I've solved it.
Remember kids, be wary of the instant client version you use, dependent on the virtualization settings!
I had been installing the generic Instant Client (not aware our ESX servers sit on AMD processors, not Intel) and that worked fine internally (the CentOS install was 32-bit since our internal ESXi servers aren't 64-bit). Well lo-and-behold, even if you have a 32-bit install running on a virtualized server which is sitting on an AMD64, it still matters what instant client you install.
It was the last thing I thought to check but as it appears, everything is running fine now.
I would like to thank everyone who helped me run through every possible test to figure this out but in the end, it was my fault for not realizing the differences in the virtualizations.
UPDATE (5/21/2010)
I thought this bug had escaped me when I installed it on a new VM internally but I have now found a narrowing link.
I was trying to install this on our production server when I posted this. After a week of no progress and in need to get back to development, I outfitted a VM on our internal server with a brand new install of Crap... CentOS, and fresh installs of instant client and oci8.
Worked perfectly.
However we just uploaded an exact copy of the VM to our production servers and it magically no longer works. Tried reinstalling everything, no avail.
So the only things I could narrow it down to is a firewall issue (although I get the same issue when trying 127.0.0.1) or possibly an ESX (our production servers) server issue, internal servers are running ESXi.
Any thoughts?
UPDATE (3/8/2010) I installed Xdebug and have it tracing my code. This is the output I am getting:
TRACE START [2010-03-08 17:53:05]
0.2090 327864 -> {main}() /data/aims3/http/octest.php:0
0.2091 327988 -> ini_set(string(14), string(1)) /data/aims3/http/octest.php:3
0.2093 327920 -> error_reporting(long) /data/aims3/http/octest.php:4
0.2094 328048 -> oci_connect(string(8), string(8), string(25)) /data/aims3/http/octest.php:6
The trace halts at that point.
I have installed everything the same way on a local server and it works fine. To say I am at a complete loss would be putting it lightly.
*NOTE: I ran make test and it returned FAIL on every test. I never ran this on my working machine to see if it reports the same errors. Any idea why make test would report FAIL but make doesn't report any error?
I've installed the Oracle Instantclient with no reported errors along with the OCI8 PECL package and at a loss. Whenever I try to open a connection with oci_connect, it halts my entire PHP script.
EXAMPLE:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
$conn = oci_connect("username", "password", "host");
echo "after";
?>
Returns a complete blank page. The module is loaded (seen in phpinfo) and everything installed with no errors.
I am at a complete loss.
CentOS: 5.4
Apache: 2.2.3
PHP: 5.3.1
InstantClient: 11.2
oci8: 1.4.1
Any thoughts?
NOTES
Apache Error Log reports nothing
Attempted Debugging:
1:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
echo "after";
?>
Returns:
beforeafter
2:
Changing host to //host
Returns:
Same error
Is there anything in Apache's error_log? Is this mod_php or FastCGI or normal CGI PHP? What happens if you run the script via the command line?
You could also try setting PHP's error log and looking in there.
EDIT1: Try:
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
And post the results...
EDIT2: I'm really not sure. My best bet is this info from the PHP manual:
The most common problem with
installing OCI8 is not having the
Oracle environment correctly set. This
typically appears as a problem using
oci_connect() or oci_pconnect(). The
error may be a PHP error such as Call
to undefined function oci_connect(),
an Oracle error such as ORA-12705, or
even an Apache crash. Check the Apache
log files for startup errors and see
the sections above to resolve this
problem.
Anyone else have any ideas to help out Bryan?
Bryan,
I am going to be honest: I tried this two years ago and failed miserably. :) I could not get the OCI functions to work for anything by compiling myself.
But in the interest of getting it done I looked for an alternate solution and found it in Zend Core for Oracle. All I did was download, run the installer, and it was done. It installs Apache/PHP, MySQL (optional), and the InstantClient for you.
Now as Zend Server, it is basically the same product. I realize that this may not be the solution you hoped for, but if it works...
Zend Server
are you connecting to remote or to local db? i think, for localhost you must replace "host" with "false". I hope, this will help you...
edit: i think, you are missing a parameter...my last suggestions are: 1. you must set the port (default 1521) AND/OR 2. You must enter db name AND/OR you must set the instance name (the ORACLE_SID parameter)
You never check the return value of oci_connect() or call oci_error() but it doesn't look relevant to your problem since you seem to be suffering from a PHP crash. There's an open bug for RHEL that may affect you too:
http://pecl.php.net/bugs/bug.php?id=16626
Did you build the oci8 package yourself? Are you using a third-party binary?
It has been fixed. See the top for details but here is the cliff notes: virtualiztion environments matter.