docker-mailserver: [NOT A BUG] Fresh 10.2.0 container crashes while booting: Failed to remove ClamAV configuration

always good if your container can just restart and recover itself.

Fair point. We should improve this. I agree that the error handling in this case is a but harsh.

@casperklein shall we emit a warning now, instead of logging a fatality?

I think Casper will address it as he worked on the previous PR that introduced this change. If not I’ll take care of it within the next day or so.

There doesn’t appear to be any reason to aggressively shutdown the container for those checks, the value is still there if using warning logs instead.

Thank you for raising the issue, it was helpful and it should be taken care of before the official release 😃

I’m not sure how you’re starting your containers, but here is the two ways to do this and avoid this problem:

• docker run --rm
• docker-compose up --force-recreate

And then add any extra options you normally have. The docker example will remove when container is stopped, while docker-compose will always recreate the containers.

to ignore such not-really-errors?

And if you later have something that would be a silent error because you didn’t create a fresh container?

I think it’s fair though. If other maintainers agree that it would be better to emit a warning instead. I don’t think we have a need to explicitly shut the container down for this error handling.

For me this behavior is a bit weird and uncommon that I need to recreate the whole container instead of restarting it. Can’t it be fixed, this is much nicer to be able to just restart the container?

You’d need a compelling case for it I think. As I explained in my last comment, it can be easy to accidentally get different behaviour that we can’t workaround, so it’s better to detect that early on.

If you really want to avoid this, you can override the error handling here, just remove the content on each line from || onwards. You can either build custom Dockerfile, or volume mount over it in the container.

Oooh ok now I understand, but why is this happning?

Your previous workflow (docker start/stop) might work, but it’s not best practice. With the new version, we introduced a stricter error checking. So these files couldn’t be deleted in the old version as well, but no error was shown.

Think of containers like the were toilet papers (should only be used once 😄). As a thumb rule, containers shouldn’t be stopped and started again.

Okay. Sorry. I didn’t know that 😞 I thought you would mistake .env file with mailserver.env

TIL that there is another crazy way to provide container variables 😄

So removing the container should be considered only if the container for a serious reason fails. Otherwise restart is the clean way.

Can you expand on the doc reference? That’s an area I look after, I’m going to take a guess you’re referring to restart: always in the config example?

That’s not necessary for cert renewals AFAIK, and it’s for the non-docker-mailserver containers, which I believe use the Docker API to restart the containers if necessary regardless of the setting.

When you restart a container, ENV changes don’t carry over IIRC, which can be unexpected. The clean way is re-creating a container as we advise as no state is persisted. Should the container encounter a failure and be eligible to restart itself, ideally it should be able to recover that way though, I’m not against that.

I am not sure if I understand you correctly, so please correct me if I did not get your point correctly.

Restarting the container (or at least the service that uses the certificate) is necessary in most cases (I am not sure what about postfix), but in general you would restart the services after renewing the certificates. That is what all other services (and docker containers) do. Actually I know no docker container that requires removing and recreating the container as a better solution than restarting. Of course if the container is stateless is good. I am just trying to say that nor restarting nor recreating should be better the other, they both should be good, imo.

@polarathene sorry I did not mean ignore literally. I just meant to log them as warnings without crashing. This is gonna be the best.

If it is possible please try to get it in this version, because this is directly related to a change done it it.

Thank you all for this discussion!

@polarathene @casperklein thank you for the explanation! At least I understand the whole thing now.

To be honest, I see it as a bad behavior, you don’t know what can happen with your server or container, and it is always good if your container can just restart and recover itself. I know it is good that you know exactly that something went wrong, but you may have that as a very emphasized log entry, but to just crash the container for such minor error is not something I would see, imho.

Can’t we have the ability to configure this behavior as environment variable to ignore such not-really-errors (I mean to log them as warnings)?

So something like this:

AUTO_RECOVER=1

or

STRICT_ERROR_HANDLING=0

@casperklein, recycling everything is always good 😄

This can happen for example, if you use docker-compose up and then hitting CTRL-C. This will just shutdown but not delete/destroy the container.

@MohammedNoureldin

The error occurs, when you do not fully shutdown (destroy) the container. On next start, the files are already gone because they were deleted previously.

In any case, you must run docker-compose down.

In doubt, check if the container is really gone with docker ps -a.

If you see something like this:

CONTAINER ID   IMAGE                               COMMAND                  CREATED         STATUS                     PORTS     NAMES
aad9522a93e9   mailserver/docker-mailserver:edge   "/usr/bin/dumb-init …"   7 minutes ago   Exited (0) 2 minutes ago             mailserver

then issue docker-compose down. Otherwise, THIS “already used” container will be used by docker-compose up again.

Stop. Variables in the file .env are not passed to the container. However, the vars in mailserver.env are passed to the container.

# .env
IT_WORKS=42

# docker-compose.yml
version: '3'

services:
  try_it:
    image: alpine
    container_name: try_it
    environment:
      - IT_WORKS
    tty: true

And now it works:

$ docker-compose up -d && docker exec -it try_it ash -c 'echo "${IT_WORKS}"'
42

You can add env_file for a custom env file, but you’ll still find vars passed through environment override it.

Good news: I can replicate your issue. Bad news: You probably didn’t do as adviced 😉