Question: Failing Symfony Application in Cloudrun?

[patriksimms]

I'm just getting starting with nginx unit and I am currently trying to port a symfony application to a docker container with unit.

I started with the symfony demo application, to ensure that nothing from my code breaks something. I used the example configs from the documentation, just changed the port to 80.

Locally everything works perfectly, but when I use the build docker image in Google Cloud Run, I get a 503 with "Service Unavailible" everytime. I can't find anythin useful in the logs, it just seems that the service is starting again and again.

To make sure it is not my docker setup which is breaking, i commented out everything in index.php and added a simple echo, and voila it works. So I guess it has to to do something with symfony, but I can't see what I am making different than local.

You can find the code here: here

Hopefully someone here has an Idea. Loving the tool so far :)

[ghost]

Hi, @patriksimms ,

Can you share your container log, please?

[patriksimms]

@artemkonev Sure. Added the links here

(Same logs, just different format). Created a new cloud run revision, waited a bit and then performed 2 requests via browser

[ghost]

Unit seems to run normally; are there any Symfony logs available as well? It might take some time to reproduce your setup, it seems.

[patriksimms]

I think symfony does not even reach a point where to produce logs. Just checked again with re-enabeling monolog in the cloud run instance. There are no other logs produced.

This however, are the logs which are produced when running the container locally (after getting the index page):

php_1  | 2020/05/18 13:59:50 [info] 12#12 (ABS_MODE) php script "/index.php" root: "/var/www/public"

php_1  | [2020-05-18T13:59:53.626554+00:00] request.INFO: Matched route "homepage". {"route":"homepage","route_parameters":{"_route":"homepage","template":"default/homepage.html.twig","_locale":"de","_controller":"Symfony\\Bundle\\FrameworkBundle\\Controller\\TemplateController::templateAction"},"request_uri":"http://localhost/de","method":"GET"} []

php_1  | [2020-05-18T13:59:53.705720+00:00] security.INFO: Populated the TokenStorage with an anonymous Token. [] []
php_1  | [2020-05-18T13:59:53.829589+00:00] request.INFO: Matched route "_wdt". {"route":"_wdt","route_parameters":{"_route":"_wdt","_controller":"web_profiler.controller.profiler::toolbarAction","token":"0faa77"},"request_uri":"http://localhost/_wdt/0faa77","method":"GET"} []

As far as I can see, the last matching line is the (ABS_MODE) line. So the application does not even proceed to the route matching i guess.

hint I just added a docker-compose.yml to the repo for everyone who wants to try it locally.

[joanfabregat]

I've the same problem with a similar configuration (Symfony + PHP + Nginx Unit + GCP Cloud Run). My Cloud Run logs are full of:

sendmsg(16, -1, -1, 1) failed (32: Broken pipe) process 33 exited with code 0

Does anyone has an idea what's causing this bug?

[sca1235]

Similar issue. Was hoping unit was ready for production guess not.

broken pipe etc. not sure what happened. is there some config should do for optimial exp.

"applications": {
    "laravel": {
        "type": "php",
        "limits": {
            "timeout": 20,
            "requests": 1024
        },
        "processes": {
            "max": 10,
            "spare": 5,
            "idle_timeout": 30
        },

[ac000]

How reproducible is this? Every request?, certain requests? Random?

What does the client side look like when this happens? 5xx error response?

Of course if you have a simple reproducer...

[sca1235]

How reproducible is this? Every request?, certain requests? Random?

What does the client side look like when this happens? 5xx error response?

Of course if you have a simple reproducer...

Not easily reproducible. Our app has been running 24 hours since the last crash without a container exit so i think we fixed it.

Went through logs and think a spike in requests or a heavy job was what took down unit with the exits.

We also lowered spare processes down to 2. Some kind of tuning guide for unit config would help.

So, to resolve it we doubled our CPUs and more ram. Then we saw opcache wasn't enabled so turned on that.

Now everything working fine will check back in if crashes again. Maybe some weird memory / proc leak..