[Plugin: Jetpack by WordPress.com] Won't connect to WordPress
-
Jetpack/WPStats stopped working. I reinstalled and now get this message when trying ot connect to WP:
“Jetpack could not contact WordPress.com: register_http_request_failed. This usually means something is incorrectly configured on your web host.
SSL connection timeout”
My host says it’s a Jetpack glitch, and based on previous experience with WP Stats, I tend to believe them.
-
Hey Tim,
Thanks for getting back to me. Our servers in fact run suPHP and I’ve verified that multiple child processes can be spawned. But this is what I’d like to be able to do. I’d like to be able to trigger JetPack so I can watch the processes open. Ideally, this should tell me if there’s an error.
So my next question is how can I trigger JetPack while I’m watching the server for the process. It’s a shot in the dark but I’m hoping this will shed some light as to what’s going on.
The funny thing is, we have a test account that we run JetPack on and it works fine. We’ve never encountered any issues. I’d like to believe that since we have quite a few customers using JetPack that this issue would have cropped up prior to now.
In the end, I’m just hoping to find a solution for our customer. Any light you can shed on this would be greatly appreciated.
thanks!
Tim S
Tim S,
Could you try running these two tests from the host in question?
https://dl.dropbox.com/u/268379/jetpack-tests/jetpack-test-outgoing-http-request.php
https://dl.dropbox.com/u/268379/jetpack-tests/jetpack-test-nested-incoming-http-requests.php
Install those PHP files on the host somewhere web-accessible and run them from the browser. Don’t run them from the command line.
The first attempts to talk to jetpack.wordpress.com over HTTPS. The second mimics a piece of the Jetpack connection process: An outgoing request from your machine to jetpack.wordpress.com, which generates an incoming request from jetpack.wordpress.com to your machine and waits for the response to that incoming request before responding to the initial outgoing request.
Both tests should say “OK” on the last line when you run them.
As for triggering Jetpack, the easiest way is to log into the blog in question as an administrator, activate the Jetpack plugin, and attempt to connect it to a WordPress.com account. You can always disconnect it later after you’re done with the tests.
Hi Michael,
Thanks for getting back to me. I’ve ran the two files up on the server in question and ran the files from a browser. I’m seeing a get request displayed inthe browser window but that’s it.
I also ran a strace from the command line to watch the processes spawned. Both test files seem to be killed when they try to write to the server. The server response is “resources temporarily unavailable”
This has led our tech support team to believe it’s attempting to open up too much at once for the server and thus the server killing the connection.
Any advice you can lend on this would be greatly appreciated.
Thanks!
Tim S,
Which server are you talking about? jetpack.wordpress.com or yours?
https://dl.dropbox.com/u/268379/jetpack-tests/jetpack-test-outgoing-http-request.php is a really simple “get a remote URL over HTTPS” script. If it fails for you when run in the browser, does it also fail when you run it from your host’s command line?
If you edit the script and change the “https” to “http” does it still fail from the browser? The command line?
I put the scripts on our server here at InMotion. I ran the scripts here and that’s the results it produced.
When I run the script from the browser via HTTP this is the result I get:
`GET: https://jetpack.wordpress.com/jetpack.test/1/If I run the same script via HTTPS, I get a Page Not Found error.
If I run from the command line, I’m not getting any errors. I get the same results as in the browser.
I’m not sure what results the test scripts should produce.
Thanks!
Tim S,
By “which server are you talking about” I meant which server in the following statement of yours.
I also ran a strace from the command line to watch the processes spawned. Both test files seem to be killed when they try to write to the server. The server response is “resources temporarily unavailable”
The output of the script should look something like:
GET: https://jetpack.wordpress.com/jetpack.test/1/ HTTP/1.1 200 OK Server: nginx Date: Wed, 18 Apr 2012 18:39:26 GMT Content-Type: text/plain;charset=utf-8 Transfer-Encoding: chunked Connection: close Vary: Cookie X-Pingback: https://jetpack.wordpress.com/xmlrpc.php Expires: Wed, 11 Jan 1984 05:00:00 GMT Last-Modified: Wed, 18 Apr 2012 18:39:26 GMT Cache-Control: no-cache, must-revalidate, max-age=60 Pragma: no-cache X-hacker: Jetpack Test OK
The test scripts both depend on curl being installed and available to PHP. If you don’t have curl available on your host, let me know and I can write a better test.
Hi Michael,
Thanks for getting back to me. Curl is enabled on the server (InMotion) here’s a link to the php.ini file to verify:
I’m not getting any results past the first Get command displayed. These scripts are located here:
When we strace the php files on the InMotion server, we see an error is thrown on the third process when it tries to write to the server. The error in the strace is “Resources Temporarily Unavailable” and the connection at that point is killed.
Systems Administration seems to think this is due to too many process or files being opened at one time so the server closes the connection.
What are your thoughts on it?
Thanks again for your help.
Both scripts take about 10 seconds before failing. 10 seconds is the timeout for both connection and data transfer in the remote request.
To see which phase is failing, you could set one of the timeouts to 5 seconds. Set CURLOPT_CONNECTTIMEOUT to 5, for example, in both scripts.
It should be possible to figure out from the strace too.
Another good test would be to edit the script to make a remote request to example.com or google.com or something other than jetpack.wordpress.com.
Then, if the script still fails, it’s clearly not the fault of jetpack.wordpress.com ?? It must either be a problem with your host or the script itself.
Our servers respond to a lot of requests, so I don’t think the resource limitation is on our end. It seems more likely that your host is limiting the resources available to any given user or process. Maybe an open file descriptors limit?
You can send the full strace to https://en.support.wordpress.com/contact/?jetpack=needs-service if you want me to look at it.
Mention me (mdawaffe) and let me know here if you do that so I can look at it promptly.
Hey michael,
Thanks for getting back to me so quickly and I appreciate you looking into this. By no means am I accusing JetPack- ultimately I’m just trying to find a solution for our customer. I’m getting ready to leave for the day, so I’ll run the strace and send you an email with the results for your review tomorrow morning.
I’ll also modify the scripts code and see if I can narrow it down that way. I appreciate the time and effort you’ve put into this thus far. It speak to the character of JetPack itself.
Thanks again!
I didn’t think you were accusing anyone. I hope you don’t think I’m making accusations either ??
We’re just trying to get to the bottom of it too.
I’m not ignoring you guys, just feeling a mix of stupid and PIA. I never imagined this would be such a hassle, and I must add that I’m impressed that both parties are taking it so seriously.
FWIW, I’ve added a few other stat plugins, all of which provide some useful information, but I really miss WP Stats because it gave me what I needed in a real-time snapshot, right on my dashboard.
Sorry that I got a bit testy earlier on. It was the frustration of an end-user who expects things to just work. ??
I don’t know who did what, but on a lark I tried and was able to activate JetPack and connect to wordpress.com. I now have the site stats feature, though there’s a big chunk of missing data.
Oh well, I was really missing some of the features that WP Site Stats offer that no other plug-in seemed to offer, notably the ability to see where traffic was coming from at any given time.
Thank to whoever made things work again. I’m marking this topic resolved, though it is unfortunate that no one else will know what the resolution was. Gremlins?
Hi there,
This is by far the most comprehensive and relevent thread I’ve found on this issue, and I hope how the problem was resolved gets posted here. Jetpack’s an awesome plugin; doing would save a lot of time for everyone who’s having trouble connecting to it (including me).
Michael Adams, Tim S: help a brother out?
- The topic ‘[Plugin: Jetpack by WordPress.com] Won't connect to WordPress’ is closed to new replies.