I have very strange problem with my application, upon occasions I get following error when connecting to postgres. This happens without any pattern, often happens when I run some extensive selenium tests.
Warning: pg_connect() [function.pg-connect]: Unable to connect to PostgreSQL server: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
Postgres logs shows no abnormalities, also other applications that run on same postgres instance have no problems at all.
My Postgres is 8.2.9, running on windows 2008 server
Any hints ?
"server closed the connection unexpectedly" most of the time means the backend crashed. If that's the case there should be some lines about it in the server log.
And by the way the latest version in the 8.2 branch is 8.2.12. Upgrade, test, report.
A random guess. Do you use persistent connections?
You're only showing the client error. Since it means that something happened on the backend, you will need to look in your server logs for information about what actually happened. (The postgres logs and/or the eventlog - check both)
A typical reason for these things to happen is if you are running some antivirus software on the server. If you do, try uninstalling it (not just disabling it) and see if the problem goes away.
Related
Recently, from few weeks ago I got err_connection_timed_out just sometimes while working with my website.
and i am sure, my users get this error too.
When i see at error log, there are a few of message like below
PHP Warning:mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock
I changed 'localhost' to '127.0.0.1' for TCP connection instead of Unix socket, but no success.
My server host admin do not accept any problem at server side (like always!).
I asked them to restart Mysql, but they do not accept because it is a share server.
It is a Directadmin server and they recommend switch to Cpanel as the last chance.
Do you have any experience and solution for this problem?
EDIT: The main problem is err_connection_timed_out which i get in browser and i don't know if it relates to Mysql connection error in log file.
Switching might have positive effects because it's differently setup.
But if it happens sometimes it is probably the MYSQL server is burping.
Lately it's normal that the services has limit per user; so you can try to enable cache (of that is possible); to see whether it's less frequent (might be some queries that is running long).
do you have any cronjobs running or other processes around the time you receive those errors?
Normally this problem is caused due to MySQL server timing-out database connections is faster than the Stash connection pool can notice. This exhausts the Stash connection pool as it will keep its connections open while the MySQL side of the connections is already closed.
Easiest solution.
You can fix it by simply change this parameter (wait_timeout) at the Mysql config.
More difficult but better
Also you can close all connections in your code after you got the values. And finally you can change your connection to your database in order to reuse an existing connections.
And last but not least
Try a vps you got out there too many oferts, even for free. You wouldn't be able to change anything in a shared host sorry. :(
I'm using mysqli connection over ssl,
so using in code following:
$mdbconnection = mysqli_init();
$mdbconnection->ssl_set('/ssl/xyz.pem', '/ssl/abc-cert.pem', NULL, NULL, 'AES256-SHA');
$mdbconnection->real_connect(SV_SERVER, SV_MYSQL_LOGIN, SV_MYSQL_PASSWORD, SV_MYSQL_DATABASE);
I noted down that I am not able to connect over mysql server all the time.
if trying 100 times failing 3 time.
and getting following error
echo($mdbconnection->connect_errno);
printing:
2003
and if I am trying second time after failing it{echo($mdbconnection->connect_errno);} will give always 1045.
I am trying to solve this bug.
Any ideas would be appreciated.
The 2003 error code means the connection couldn't be established:
https://dev.mysql.com/doc/refman/5.5/en/error-messages-client.html
Error code 1045 means the client connected but the server rejected the credentials (access denied):
https://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html
I'd say that if you're getting the 2003 error code a few times out of every 100 tries, it sounds like some of the possibilities could be:
Some intermediate application or piece of hardware might be seeing your attempts as a possible flood attack (DDoS) and could be intercepting and blocking the connection (if you're connecting 100 times really quickly)
You might have some network stability issues on the client side. It might be worth the time to run Wireshark and reproduce the problem with it running in order to capture the problem and see if it shows anything significant (e.g. DNS failure).
The MySQL server might be crashing and then restarting. Check your server-side MySQL error log (https://dev.mysql.com/doc/refman/5.7/en/error-log.html). Actually, you should really do this as a first step any time you have bizarre behavior in MySQL.
If the MySQL server log doesn't show anything, check your system logs, especially if you're logging anything like blocked firewall (iptables or whatever f/w you're using) packets and search them for your client IP around the time of the problem.
Finally, if you can reproduce this easily/quickly (e.g. make 100 connections via a script and see it fail), try eliminating SSL out of the equation and connecting without SSL and see if it gives you the same problem. If it works flawlessly without SSL, perhaps there's a problem with the SSL library that was used during the compilation of your MySQL package.
You might also want to check to see if you have any load-balancing in place that might make your script connect to different instances of the MySQL server (this is less likely, but could explain the symptoms you're seeing if one server is down and the next doesn't have the credentials you're providing)
OpenSuse Leap 42.1 (latest upgrade)
Apache2, PHP 5.5 installed
OCI8 installed
ORACLE 11g
Last week, I got some update issues with KDE and did an upgrade of OpenSuse Leap 42.1. I then went over the whole procedure of installing oci8 (as described in http://php.net/manual/en/oci8.installation.php and making sure to use the correct PECL) and everything worked fine.
But when I restarted my system a few hours later, I was't able to connect via hhtp to any vhost due to failed connection to the database.
I get no error logs anywhere, just a white 404 page or the message "Error: Could not connect to database. Aborting." (depending on which page I'm calling). Pages with no connection to the database work perfect!
SQLDeveloper connects without any proble, using the same parameters as in the config-files for the vhosts.
Anyone any idea?
Generally when you get a
ORA-12514
it means that the listenr you are connecting to knows not the servicename/SID you're attempting to connect to. If you get that error it should indicate that the client got some sort of response from the listener which should exclude all sorts of network issues.
This is very much similar to ORA-12514 TNS:listener does not currently know of service requested in connect descriptor
only that the issue sprouted up after an update.
I would first look in the client side tnsnames.ora and the server side listener.ora to check that everything is ok. Also check that the database is registered on the listener. Possibly also check that the db is remotely reachable from a known good client to exclude any issues on the listener configuration.
problem(s) solved!
as there were two different of them provoking a problem salad.
first, the update somehow managed to change some parameters in my config files, first of all the database name.
then, apache update from 2.2 to 2.4 DID change some things in the vhosts config files and therefore the errors were never logged in the former x_error.log and the 404 message was shown.
thx a lot for your response, louigi600!
I have an issue with a mysql database that randomly just go and die obviously. When this occurs and I try to use mysql in the terminal this occurs:
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'
What causes this? If I restart the service it works splendid until the next random occurance when it stops working again. Am all open for ideas.
You are not mentioned your OS, mysql version, XAMPP/WAMPP here. There are some reason for this error.
If OS is windows.
If you have installed XAMPP more than one in various driver of your system, this error may happen
If you installed skype, It may be using mysql default port 3306.
Clear your browser cache and try it.
Issue was memory related. The system killed processes for more essential parts.
We've got an ongoing issue where php 5.2.6 will quit connecting to Oracle 10.2.0.4.0. We can go weeks without any issues and then (usually Saturday mornings) php will no longer be able to connect. The database is up and running and we can connect to it manually with varous DB tools but php won't ever connect again until we reboot the web server. The web server is running IIS 6.0.
We connect using $connection = oci_connect ($userID, $password, $TNS) where $TNS is the appropriare TNS in the local tnsnames.ora file. We go through a connection manager at our data center but I don't know the details on how that works.
One of the reasons this has been dogging us is that we're not really sure who is causing the problem and the various logs haven't shed any light on that. Is it a php issue as it would appear or is the DB itself for some reason rejecting the connections, or is it perhaps the connection manager? Some input in figuring that out would help a lot. Our load is lighter on weekends so that should be the issue. We haven't been able to find any outside processes that could be initiating the problem.
Not really a "root cause" solution, but if you're not using FastCGI, a switch to FastCGI might help with this issue. A PHP process in FastCGI does not live for "weeks". Since the oracle client is loaded dynamically into the PHP process, the automatic process restarts you get with FastCGI should be identical to a web server restart. You can always tweak the FastCGI settings to restart the process more or less often.
If you're using ISAPI, that probably is your root cause though. PHP and ISAPI are bad news when combined. Problems are almost inevitable.