Caddy: FastCGI persistent connections not reconnecting

Created on 21 Sep 2016  路  8Comments  路  Source: caddyserver/caddy

1. What version of Caddy are you running (caddy -version)?

0.9.2. This behavior does not occur in 0.9.1, which as far as I can tell was before persistent FCGI connections were added.

2. What are you trying to do?

Use fastcgi to run php-fpm

3. What is your entire Caddyfile?

redacted.com {
    fastcgi / 127.0.0.1:7698 php {
        index index.php
    }
    root /srv/www/redacted.com
}

4. How did you run Caddy (give the full command and describe the execution environment)?

Ubuntu 14.04
/opt/caddy/caddy -conf=/etc/caddy/Caddyfile

5. What did you expect to see?

Continued success loading PHP files.

6. What did you see instead (give full error messages and/or log)?

After pm.max_requests as defined in php-fpm, the worker is killed and recreated, killing the FCGI connection. Caddy doesn't reconnect, return 502s and putting this in the log:
21/Sep/2016:20:12:59 +0000 [ERROR 502 /] write tcp 127.0.0.1:41784->127.0.0.1:7698: write: broken pipe

This also happens if php-fpm is restarted.

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

Use the fastcgi directive and restart php-fpm. Caddy will need to be restarted to continue serving PHP output.

bug

Most helpful comment

Working on a fix. Also, I want to make it configurable in the Caddyfile so users can disable it.

All 8 comments

Working on a fix. Also, I want to make it configurable in the Caddyfile so users can disable it.

Thank you @abiosoft!

I have made persistent fastCGI configurable (this was still on my todo list, didnt see that you are on it, @abisoft, sorry)
https://github.com/mholt/caddy/pull/1126

However, this only means that you can toggle between the former state of afairs (no persistent connections, reliable but slow on Windows) and the current one (fast but unstable), non of which is really satisfactory. A proper fix might mean rewrigthing the fastCGI backend to do proper demuxing + reconnect if neccessary. I will investigate

The fix for this was merged, thank you for the reports! And of course thanks to Abiola and Sebastian for working on fixes. :+1:

This issue is not yet quite fixed.
Enabling pooling as in https://github.com/mholt/caddy/pull/1129#pullrequestreview-1443068 I can reproduce this bug. But I think this can easily be fixed.
https://github.com/mholt/caddy/pull/1129#issuecomment-249447914
https://github.com/mholt/caddy/pull/1134

So this is still unfixed @Echsecutor? Even in the branch?

It is now fixed in my PR https://github.com/mholt/caddy/pull/1134 where I moved the 'put back into pool' after the error handling
https://github.com/mholt/caddy/pull/1129#issuecomment-249447914
Are you referring to this branch?

@Echsecutor Ah, I see now -- there's some overlap between #1134 and #1139, it looks like your PR has the tests though. So maybe that's all that's needed.

Was this page helpful?
0 / 5 - 0 ratings