stream_socket_client debug?

[dorris]

Really hoping someone here can throw me a bone .

 

I have an application that has been plaguing me since inception, it functions well on the testbench, but once it starts to get used more seriously, it throws out occasional failures..

I have managed to point all fingers at the SSL socket creation using stream_socket_client and the SSL context.

 

The documentation at http://php.net/manual/en/function.stream-socket-client.php states:

On failure the errno and errstr arguments will be populated with the actual system level error that occurred in the system-level connect() call. If the value returned in errno is 0 and the function returned FALSE, it is an indication that the error occurred before the connect() call. This is most likely due to a problem initializing the socket. Note that the errno and errstr arguments will always be passed by reference.

 

This is unfortunately EXACTLY my case,

Error connecting to ssl://SOMENAME:3121:  (code 0)

 

I get returned false from the call, but error is 0, so the problem is not particularly code related, but how would I debug where the problem took place.

what could cause a problem initializing the socket, and how do I debug these steps?

 

I am using centos6.3

Apache 2.2.15

php5.3.3

suphp 0.7.1

 

 

Thanks in advance for any assistance in this regard.

 

[lemmin]

Possibly maximum number of connections?

[dorris]

Any ideas how to change/debug that to determine exact cause?

 

#netstat -n -p|wc -l

At its highest point shows about 180 , which as far as I can tell is nowhere near my limits ?

Is there perhaps a flag in apache to limit this?

 

See output of ulimit -a below:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 125140
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 16384
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 4096
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

 

[requinix]

Delve in with strace to see which library call is returning failure and probably its error code - put an exit/die right after the code that fails to limit how much logging you'll have to sift through (leaving the important results near the very bottom). You should be able to get a specific reason for the problem from that.

[dorris]

Thanks for feedback.

Solved the issue, was caused by a bad path to SSL cert when executed from certain modules, so it was the CONTEXT that was invalid, hence the socket could not be opened, and returned errcode 0

 

dont I feel stupid, spent a good 20 hours looking for this