We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The healthcheck is configured to check "localhost:1080", which works iff the web interface is bound to port 1080 and "whatever-localhost-resolves-to".
Unfortunately this breaks for me (Intel mac + podman):
0.0.0.0
maildev/lib/web.js
Line 118 in 87eceb0
/etc/hosts
localhost
127.0.0.1
::1
Log from wget (trimmed a bit to remove podman-compose noise):
$ podman-compose exec maildev wget -O - http://localhost:1080/healthz Connecting to localhost:1080 ([::1]:1080) wget: can't connect to remote host: Connection refused exit code: 1
I can set MAILDEV_WEB_IP to ::.
MAILDEV_WEB_IP
::
"Things work just fine". But, that's not trivial I think:
So maybe this could be instead added to the documentation?
The text was updated successfully, but these errors were encountered:
The healthcheck also fails if you set the base-pathname to a non-default value via the --base-pathname option (or MAILDEV_BASE_PATHNAME env var).
--base-pathname
MAILDEV_BASE_PATHNAME
Sorry, something went wrong.
Same here. If I configure the ports via environment variable in a docker-compose file the healthcheck checks the wrong port.
Successfully merging a pull request may close this issue.
The healthcheck is configured to check "localhost:1080", which works iff the web interface is bound to port 1080 and "whatever-localhost-resolves-to".
Unfortunately this breaks for me (Intel mac + podman):
0.0.0.0
(seemaildev/lib/web.js
Line 118 in 87eceb0
/etc/hosts
that resolveslocalhost
to both127.0.0.1
and::1
Log from wget (trimmed a bit to remove podman-compose noise):
Workaround
I can set
MAILDEV_WEB_IP
to::
.Expectation
"Things work just fine". But, that's not trivial I think:
So maybe this could be instead added to the documentation?
The text was updated successfully, but these errors were encountered: