api-platform: "Still waiting for db to be ready... Or maybe the db is not reachable."

For me this was cause by removing apk add pdo_pgsql \ in my api/Dockerfile

I copy some of another Dockerfile, and replace this by pdo_mysql \

I search a lot on the web and found nothing, hope it can helps someone

Hi, I have also this problem. For a week now, I don’t now why it’s work on my local (Windows) but not in my server (VPS at OVH)

Process

• Start with a fresh project with git clone or package from the repository
• Build with docker-compose up --build.

Results Local: 200 /ping
Server: Still waiting for db to be ready... Or maybe the db is not reachable.

I juste solve my problem with chmod +x api/bin/console 🤯

Let’s do this! Do you want to work on a PR?

I started to but…

I mixed up two bugs reports for the same kind of problem. The other one was not related to api-platform but involved bin/console too.

So, here the problem is for the “Still waiting” because bin/console is not executable in some situations. It’s not because of a composer doing a cache:clear… I mixed up.

Back to this problem:

I tried different ways to install and run api-platform.

1. Under WSL2: git clone and run => No problem on bin/console
2. Under WSL 2: dl .tar.gz, untar, run => No problem
3. Under Windows: dl .tar.gz on Windows, move the archive in a WSL2 dir, untar with WSL2, run => No problem
4. Under Windows: dl .tar.gz, untar it under Windows into a WSL2 dir, run => bin/console is not executable and got the “Still waiting for db…”

I did chmod +x on bin/console under WSL2, ran docker-compose up again and the problem was solved.

So, it can’t be fixed in the Dockerfile. It’s a Windows and/or WSL2 problem only.

• Wacuta may have done unzip/untar with Windows, lost flags, uploaded files on his VPS
• Me, I untar the files under Windows into WSL2 dir. I don’t know how Windows do this, but it seems he doesn’t keep flags even if we untar files directly to a WSL2 dir.

The problem is because of Windows. Even with the .tar.gz file 😕

Maybe should we use php bin/console everywhere instead of bin/console?

I checked permissions for bin/console on the repo. It’s 0755, so it’s not a repo or archive problem. It’s not the most elegant way to solve, once for all, this problem but chmod +x is the most efficient way.

You’re already did it in line https://github.com/api-platform/api-platform/blob/master/api/Dockerfile#L105 but it’s after the first composer install command in line https://github.com/api-platform/api-platform/blob/master/api/Dockerfile#L86

Composer do a bin/console cache:clear after an install or update, so it needs to have bin/console to be executable. composer.json:

    "scripts": {
        "auto-scripts": {
            "cache:clear": "symfony-cmd",
            "assets:install %PUBLIC_DIR%": "symfony-cmd"
        },
        "post-install-cmd": [
            "@auto-scripts"
        ],
        "post-update-cmd": [
            "@auto-scripts"
        ]
    },

I know you don’t like this, but… Moving the chmod +x bin/console is the best way to solve this. A fresh Symfony have bin/console executable.

Thanks for the feedback! I don’t own a Windows computer so I cannot debug this. It would be awesome if someone using Windows can help to track this down (and to fix the bug).

It seems untaring into a wsl2 folder from Windows doesn’t keep some linux permissions, even with a .tar.gz archive.

Maybe just adding a chmod +x bin/console before the first composer install, in the Dockerfile, can solve this problem for wsl2 devs ? It’s a lot easier to untar files from Windows to a wsl2 folder than doing all the command lines directly into wsl2. 😉

I used the .tar.x file and untar under wsl2.