[eluser]Vadtec[/eluser]
[quote author="Vadtec" date="1270865984"]
...snip...
Wondering if the DB driver was even trying to connect to postgre (which I can verify is working via both CLI and phppgadmin), I fired up tcpdump. Much to my surprise, neither the web server nor the database server are seeing any packets that would be bound for postgre. I know it's not a fire walling issue on either box, and I am capturing all packets for the assigned IP(s), not just certain ports. I have tried capturing on the ports as well, and still see no packets.
...snip...
No matter what I have tried, I see *zero* packets even attempt to be sent. I have verified that apache is working, as is php. The drivers are loaded and accessible (as you can see from the paste above).
...snip
- Vadtec[/quote]
[quote author="kea13" date="1271005951"]Hi Vadtec,
a couple of pointers:
- did you verify that PostgreSQL is actually running? ("service postgresql status")
- if PostgreSQL is running, is it configured to listen on a tcp-socket? ("netstat -ntap|grep 5432")
- if PostgreSQL is running and configured to listen on a tcp-socket, do you have access to the database with the credentials given? ("cat /var/lib/pgsql/data/pg_hba.conf")
Regards,
Roman[/quote]
I think I made it very clear above that postgre is running and functioning as expected. I also thought it was clear that I was seeing
zero packets coming from the web server to the postgre port (which, yes i know, is 5432). In fact, here...
Code:
[***@<DB server> pg_log]# pwd
/var/lib/pgsql/data/pg_log
[***@<DB server> pg_log]# service postgre status
postmaster (pid 30796 30795 30794 30792 30790 6238 6226 4988 4633 4632 4631) is running...
[***@<DB server> pg_log]# note the file name, and the date it gives for when i shutdown/restarted the db server
[***@<DB server> pg_log]# cat postgresql-Fri.log
LOG: received fast shutdown request
LOG: aborting any active transactions
FATAL: terminating connection due to administrator command
LOG: shutting down
LOG: database system is shut down
LOG: logger shutting down
LOG: database system was shut down at 2010-04-09 13:38:14 EDT
LOG: checkpoint record is at 0/B98DB90
LOG: redo record is at 0/B98DB90; undo record is at 0/0; shutdown TRUE
!!!This is where the database is restarted.!!!
LOG: next transaction ID: 492679; next OID: 18379
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system is ready
LOG: transaction ID wrap limit is 2147484148, limited by database "***"
[***@<DB server> pg_log]# netstat -ntap|grep 5432
tcp 0 0 <IP removed>:5432 0.0.0.0:* LISTEN 30790/postmaster
tcp 0 0 <IP removed>:5432 <IP removed>:59948 ESTABLISHED 4633/postgres: <DB user name removed>
tcp 0 0 <IP removed>:5432 <IP removed>:59947 ESTABLISHED 4632/postgres: <DB user name removed>
tcp 0 0 <IP removed>:5432 <IP removed>:59946 ESTABLISHED 4631/postgres: <DB user name removed>
tcp 0 0 <IP removed>:5432 <IP removed>:43445 ESTABLISHED 6226/postgres: <DB user name removed>
tcp 0 0 <IP removed>:5432 <IP removed>:34799 ESTABLISHED 6238/postgres: <DB user name removed>
tcp 0 0 <IP removed>:5432 <IP removed>:57802 ESTABLISHED 4988/postgres: <DB user name removed>
As you can clearly see, the database server is running just fine. The DB user name that was removed is the exact same user name that cannot connect via CI. If I were to run tcpdump, we would see packets between the two IPs. If I were to run tcpdump on the web server, we would see zero packets coming from the web server to the DB server. I suppose if you don't believe me I could record my screen and show you, but I really do think that is pointless.
I really do appreciate you trying to help, but if you cannot read the information I have given you and deduce that I have more than enough experience running web and database servers to know how to set them up and access them, please don't respond. I need answers, and no amount of code delving into CI has turned up any results. Yes, I delved clear down into the DB driver code for CI, just to verify it wasn't a bug.
So, as I asked before, does anyone have any information as to what is going on? After some speculation with co-workers and associates, it most likely is some incompatibility with CI and the underlying postgre drivers in PHP.
That is one thing I have no time to delve into...PHP postgre drivers that is. Any help or info on the issue is greatly appreciated, but please, do try to keep it productive.
- Vadtec