This is a refrase of #1152 since the real proble is the container being unable to start
This happens also in the notls flavour
Checking processes, it seems stuck at config.py
1 root 0:00 {start.py} /usr/bin/python3 /start.py
6 root 0:00 {config.py} /usr/bin/python3 /config.py
14 root 0:00 bash
29 root 0:00 ps aux
Indeed the configuration has not taken place at /etc/nginx which has only the default nginx.conf
Trying to start nginx manually with the default conf throws an error
>>> os.execv("/usr/sbin/nginx", ["nginx", "-g", "daemon off;"])
nginx: [emerg] open() "/run/nginx/nginx.pid" failed (2: No such file or directory)
From within the front container, can you ping:
Same for webmail and webdav if you have selected those services.
I have the same issue. Containers like admin are trying to resolve the ip for the front/nginx container and because of that, they are stuck in the start up loop. This is happening due to dockers dns system which resolves only for container which are healthy.
Additional info: I use docker swarm
@j0x00 Good catch !
I made a quick test with healtcheck disabled for various services (front, admin, imap, smtp, webmail) on master, and I could launch the swarm
i just experienced the same. I had to disable all healthchecks, otherwise the containers would not be connected to the network. it seems that at least for docker swarm a positive healthcheck is mandatory for connecting the container to the network.
Basically this is intended by docker swarms dns. Only when a container reaches the state "healthy" the domain name will be routed to the containers/service ip. I have currently no clue why nginx/front has issues getting to the correct state, but the reason the admin and several other containers are stuck in the start up loop it because they can not resolve front as domain name.
@j0x00 Yes, you are right.
Regarding nginx not starting: I know that nginx refuses to start if an upstream is not available. Since webmail, antispam, admin .... are all upstreams, resolved via service-name nginx would not be start until dns is working.
The question is, how did it work in the first place ....
How did you solve the issue?
@CARB2 I personally have not checked the solution, but it was mentioned to just disable the health checks in your docker-compose.
You can do this by adding:
services:
front:
healthcheck:
disable: true
or
services:
front:
healthcheck:
test: ["NONE"]
You can read more about this here: docker compose reference: healthcheck
well, just confirm that 1.6 works even with the healthchecks enabled. Is just 1.7 where nginx seems to be broken (at least in swarm)
It's not only for Swarm. I can replicate the same bug on Kubernetes.
I have the same problem when using swarm mode.
Manually creating /run/nginx with 777 permissions and then running nginx -g 'daemon off;' allows Nginx to start.
So to me it looks like some sort of a permissions issue.
Hi There,
The Mailu-Project is currently in a bit of a bind! We are short on man-power, and we need to judge if it is possible for us to put in some work on this issue.
To help with that, we are currently trying to find out which issues are actively keeping users from using Mailu, which issues have someone who want to work on them — and which issues may be less important. These a less important ones could be discarded for the time being, until the project is in a more stable and regular state once again.
In order for us to better assess this, it would be helpful if you could put a reaction on this post (use the :smiley: icon to the top-right).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
Hi There,
The
Mailu-Project is currently in a bit of a bind! We are short on man-power, and we need to judge if it is possible for us to put in some work on this issue.To help with that, we are currently trying to find out which issues are actively keeping users from using
Mailu, which issues have someone who want to work on them — and which issues may be less important. These a less important ones could be discarded for the time being, until the project is in a more stable and regular state once again.In order for us to better assess this, it would be helpful if you could put a reaction on this post (use the :smiley: icon to the top-right).
We want to keep this voting open for 2 weeks from now, so please help out!