Calling supervisord directly instead of via shell#1074
Calling supervisord directly instead of via shell#1074johansmitsnl merged 1 commit intodocker-mailserver:masterfrom
Conversation
| @test "checking configuration: hostname/domainname" { | ||
| run docker run `docker inspect --format '{{ .Config.Image }}' mail` | ||
| assert_failure | ||
| assert_success |
There was a problem hiding this comment.
Why did you change this test? It does not seems to be related to your change?
There was a problem hiding this comment.
Supervisor is now the main process (PID 1) and we can't stop it in the start-mailserver.sh script in a way that would result in a failure. Supervisor is not designed to stop with an error if one of its processes is failing.
So there are basically two options:
- stopping supervisor gracefully or
- using a different init process.
I think 1) should be ok, since the container only failed if the setup was failing (due to configuration errors). For correctly configured containers this would not matter.
For option 2) we could either (a) use docker's built-in init process (docker run --init; or docker-compose option "init: true") or (b) add an external init program (like tini) and kill supervisor non-gracefully.
Option 2a) could be problematic for already deployed instances, since the docker-compose files (or docker run commands) need to be changed. I did not check out options for 2b)
johansmitsnl
left a comment
johansmitsnl
left a comment
There was a problem hiding this comment.
Please check the test comment.
2 participants
This fixes #1047 by calling supervisor directly. The container won't fail now anymore, because there is no way to tell supervisor to exit with an error, so I had to change the test that expects the container to fail.
I recommend increasing the stopping time, though. Since the container can take longer than 10 seconds to stop gracefully. This can be done using "stop_grace_period" in docker-compose.yml or "--stop-timeout" using "docker run" (also docker stop -t)