| 5 May 2025 |
 netpleb | once it times out, then everything works fine. I have whittled it down to acme, because when I remove any acme things the container boots up just fine and is able to route/ping quite quickly | 18:01:46 |
| netpleb | so, by that, I mean that the issue does not seem to be pertaining to (in my case) networking.wireguard nor networking.bind which are both used and operate completely fine in the container. It is only after adding something like (per the manual):
security.acme.certs."<redacted>"= {
domain = "*<redacted>";
dnsProvider = "rfc2136"; # allows us to do dns acme validation with local dns server
environmentFile = "/var/lib/secrets/<redacted>.certs.secret";
# We don't need to wait for propagation since this is a local DNS server
dnsPropagationCheck = false;
};
that the behavior occurs.
| 18:04:57 |
| netpleb | what I am most confused about (and why I am posting here) is why the call to lego --accept-tos --path . -d '*.<redacted>' --email <redacted> --key-type ec256 --dns rfc2136 --dns.propagation-disable-ans --dns.resolvers 127.0.0.1:53 --server https://acme-v02.api.letsencrypt.org/directory renew --no-random-sleep --days 30 seems to block all network traffic, even for other services (like wireguard, bind, etc) | 18:07:29 |
| netpleb | * what I am most confused about (and why I am posting here) is why the call to lego --accept-tos --path . -d '*.<redacted>' --email <redacted> --key-type ec256 --dns rfc2136 --dns.propagation-disable-ans --dns.resolvers 127.0.0.1:53 --server https://acme-v02.api.letsencrypt.org/directory renew --no-random-sleep --days 30 seems to block all network traffic, even for other services (like wireguard, bind, etc) until it times out. There must be something I do not understand about how systemd works or calls this, but I woudl like to learn ;) | 18:07:56 |
| netpleb | * what I am most confused about (and why I am posting here) is why the call to lego --accept-tos --path . -d '*.<redacted>' --email <redacted> --key-type ec256 --dns rfc2136 --dns.propagation-disable-ans --dns.resolvers 127.0.0.1:53 --server https://acme-v02.api.letsencrypt.org/directory renew --no-random-sleep --days 30 seems to block all network traffic, even for other services (like wireguard, bind, etc) until it times out. There must be something I do not understand about how systemd works or calls this, but I would like to learn ;) | 18:08:04 |
| netpleb | in essence though, as soon as I comment out the security.acme.certs... config above, the container boots up in a couple seconds, whereas with the acme config in place it takes a couple minutes since it has to wait for acme to timeout. I have tried for days now to figure out how to move the acme renewal process way later, but nothing seems to work. | 18:34:26 |
| netpleb | * in essence though, as soon as I comment out the security.acme.certs... config above, the container boots up in a couple seconds and can ping various ips and even resolve hostnames with the local BIND instance, whereas with the acme config in place it takes a couple minutes since it has to wait for acme to timeout. In the interim no pinging or hostname lookups even work. I have tried for days now to figure out how to move the acme renewal process way later, but nothing seems to work. | 18:35:53 |
| netpleb | * in essence though, as soon as I comment out the security.acme.certs... config above, the container boots up in a couple seconds and can ping various ips and even resolve hostnames with the local BIND instance, whereas with the acme config in place it takes a couple minutes to boot since it has to wait for acme to timeout. In the interim no pinging or hostname lookups even work. I have tried for days now to figure out how to move the acme renewal process way later, but nothing seems to work. | 18:48:20 |
| netpleb | (sorry for so many messages), I have continued to investigate and it seems that the root cause is that the host machine does not provide the network/routes to the container until late (possibly even after?) the container is done booting. So because of this, acme stalls the boot process. So far the only thing that has sort of worked, but is very not-clean, is for me to just put serviceConfig.TimeoutStartSec = "20s"; on the various acme-<domain>.service units. | 20:18:57 |
