fix: shutdown supervisor in healthcheck.sh on fatal error, fixes #5993

[stasadev]

The Issue

• ddev-webserver healthcheck should exit early on error with apache/nginx/php-fpm #5993

How This PR Solves The Issue

I checked https://docs.docker.com/reference/dockerfile/#healthcheck before doing any change and when we use start_period, no matter what we do during this period, the container cannot become unhealthy.

start period provides initialization time for containers that need time to bootstrap. Probe failure during that period will not be counted towards the maximum number of retries.

I also searched for a fast fail when starting the container, but that's all I found:
https://forums.docker.com/t/healthcheck-fail-fast-feature-during-container-start-up/121201

So, in the end, I decided to do the same thing as suggested in:

• fix: supervisord should not bring down the whole web container when non-essential service fails, fixes #5358 #5906

but in a simpler way.

Also I decreased startretries=10 to startretries=3 in supervisor, there is no reason to try more and wait longer, if the process cannot start several times already.

Manual Testing Instructions

See error for php-fpm after 20-30 seconds (without waiting for 2 minutes default timeout):

echo 'RUN chmod 000 /run/php' > .ddev/web-build/Dockerfile
ddev restart
...
Failed waiting for web/db containers to become ready: web container failed: log=&{2024-03-29 21:42:41.347467771 +0200 EET 2024-03-29 21:42:42.086281673 +0200 EET 143 php-fpm:FATAL Shut down
}, err=ddev-d10-web container is unhealthy: &{2024-03-29 21:42:41.347467771 +0200 EET 2024-03-29 21:42:42.086281673 +0200 EET 143 php-fpm:FATAL Shut down
}, please use 'ddev logs -s web' and 'docker logs ddev-d10-web' and 'docker inspect --format "{{ json .State.Health }}" ddev-d10-web' to find out why it failed

Automated Testing Overview

Related Issue Link(s)

Release/Deployment Notes

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR.

• Test on Gitpod.
• Test on GitHub Codespaces.

[rfay]

Just looking at the code says this is fine, will manually test, thanks!

[rfay]

This is great and works fine. The one request I have is not to include gunicorn, which I think will make it easier for python folks to debug. Gunicorn is more like web_extra_daemons in that it's easier to mess up, and when things go bad you want to be able to restart it.

I tested this with a bad nginx configuration and it behaved correctly. I also tried a bad PHP extra config, and surprisingly php-fpm just ignored that.

I really liked the clear output when nginx is the problem:
Waiting for web/db containers to become ready: [web db] Failed waiting for web/db containers to become ready: web container failed: log=&{2024-04-01 07:04:12.760287761 -0600 MDT 2024-04-01 07:04:13.11287521 -0600 MDT 143 nginx:FATAL Shut down }, err=ddev-d10-web container is unhealthy: &{2024-04-01 07:04:12.760287761 -0600 MDT 2024-04-01 07:04:13.11287521 -0600 MDT 143 nginx:FATAL Shut down

We don't get good info like that from apache or php.

[rfay]

One of the hardest things about python/gunicorn is that it doesn't stay up if we have a settings problem. I'd rather treat it like we do the web_extra_daemons. It might be a step forward with python.

Suggested change

	for service in php-fpm nginx apache2 gunicorn; do
	for service in php-fpm nginx apache2; do

[stasadev]

Rebased, and pushed the image again.

[rfay]

This worked great on my first try. I set up https://github.com/ddev/test-django4-bakerydemo and didn't remember that other things had to be done. So it failed.

But I was able to ddev ssh and study it, which is the good thing here.

And after I did the things it was OK.