Protection against running without --force-recreate, by checking container state at start? (EDIT: 14.0.0 has better protection already)

[michelcve]

I've been running docker-mailserver as a test for a while, and I really like it.

One thing that worries me a bit is the requirement to always start it with --force-recreate or use docker compose down.

I did some digging in github and the documentation, but I still have some questions.

If I understand correctly, the most important part is that the container needs to be recreated when is starts.

If I am correct, stopping it with "docker compose stop" isn't necessarily a problem, if you recreate the container as start.

Similarly I get the idea that using CRTL+C might even be possible (though I can imagine that it still could give some trouble).

Being that the most important part is recreating the container at start, I was wondering, isn't there some form of checking possible, that when the container starts, and notices a certain file exists for example, that is would error and immediately quit (preventing any damage to your data.

I'd really love to know if that's possible (would give me a warm a fuzzy feeling inside if the risk is minimized :-D).

[glime-ai[bot]]

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

This response is generated only once - you will not be able to interact with the glime-ai.

---

You are correct that the most important part is to ensure the container is recreated when it starts. This is to avoid configuration mishaps and ensure that the setup scripts run correctly. Here are some key points to address your concerns:

1. Stopping with docker compose stop: Stopping the container with docker compose stop is not recommended because it does not properly destroy the container, which can lead to inconsistent states. Instead, you should use docker compose down to stop and remove the container.

2. Using CTRL+C: Similarly, using CTRL+C to stop the container is not supported and can cause issues. It is better to use docker compose down to ensure a clean shutdown.

3. Recreating the Container: The recommended way to start the container is with docker compose up --force-recreate to ensure that the container is recreated and the setup scripts run correctly.

4. Automatic Checks on Startup: While there isn't a built-in mechanism to automatically check and quit if the container is not properly recreated, you can implement a custom solution. For example, you could create a script that checks for the existence of a specific file or condition and exits if the condition is not met. This script could be added to the container's startup process.

Here is an example of how you might implement such a check in a custom entrypoint script:

#!/bin/bash

# Check for the existence of a specific file
if [ -f /path/to/your/checkfile ]; then
  echo "Container was not properly recreated. Exiting."
  exit 1
fi

# Continue with the normal startup process
exec "$@"

You would then modify your compose.yaml to use this custom entrypoint script.

For more detailed information, you can refer to the Debugging and Usage sections of the documentation.

This comment was generated by Glime.

[michelcve]

Great, thanks mister AI :-).

But if it would be that easy, I presume it would have already been done. So I'd still love to hear from someone who understands the inner workings a bit better than me :-).

[polarathene]

You should be able to follow something like the advice by the AI here. As you can see we're doing roughly the same detection logic in my answer below.

Our image has a basic entrypoint configured that you could mimic with --init (docker run) / init: true (compose.yaml), which should allow for your own early entrypoint script:

docker-mailserver/Dockerfile

Lines 315 to 316 in 18d9d1a

	ENTRYPOINT ["/usr/bin/dumb-init", "--"]
	CMD ["supervisord", "-c", "/etc/supervisor/supervisord.conf"]

[polarathene]

One thing that worries me a bit is the requirement to always start it with --force-recreate

• docker compose up --force-recreate is required, or anything else that destroys/discards the previous container instance (explicit docker compose down).
• Only your volumes should be persisting the state, but without removing the previous container it's internal state is kept around and our scripts are a bit fragile to that.

We do have detection for when this has not been done, but it emits a warning instead.

This problem has been minimized with v14 release, as we use that logic to skip our startup scripts:

docker-mailserver/target/scripts/start-mailserver.sh

Lines 172 to 192 in 18d9d1a

	# Ensure DMS only adjusts config files for a new container.
	# Container restarts should skip as they retain the modified config.
	if [[ ! -f /CONTAINER_START ]]; then
	_early_supervisor_setup
	_early_variables_setup
	_log 'info' "Welcome to docker-mailserver ${DMS_RELEASE}"
	_register_functions
	_check
	_setup
	_run_user_patches
	else
	# container was restarted
	_early_variables_setup
	_log 'info' 'Container was restarted. Skipping setup routines.'
	_log 'info' "Welcome to docker-mailserver ${DMS_RELEASE}"
	_register_functions
	fi

That should minimize the problem, but if anything else later makes an assumption that the container is in a predictable "fresh" state (say customization via user-patches.sh), then you may have an issue there since the concern is still valid. Some users may expect some changes to occur by adjusting config files but if we skip processing that from restart detection, they'd need to follow the force recreate advice.

[michelcve]

That's great news, thanks for all your efforts?

Would it be an idea to add an environment option in which you could optionally choose to terminate instead of printing a warning? (for those being paranoid, or having a user-patches.sh like me :-)).

Of course I can do it myself now with these great answers, but perhaps it's something other users would like as well?

[polarathene]

Would it be an idea to add an environment option in which you could optionally choose to terminate instead of printing a warning?

I wouldn't object to that! 😎

Feel free to raise a feature request to get approval from another maintainer, and if you're comfortable with contributing the change raising a PR after approval 👍

[casperklein]

Would it be an idea to add an environment option in which you could optionally choose to terminate instead of printing a warning?

Keep in mind, that this can have drawbacks: If your docker host reboots or crashed for some reason (power outage), the container is not destroyed and restarted when the host comes back online. If you choose DMS to terminate when an improper restart is detected, you won't be able to receive any mails until this is manually fixed. Until then, DMS will be in a start/stop loop.

Another approach could be, to send an email to postmaster to notify about an improper restart.

[michelcve]

You've got a point there @casperklein , and if I look at the script for 14.0.0 it seems that even user patches won't be run twice, so I guess we should be good there...

Thanks all, I will close this discussion.

I really appreciate all the help here!