webserver # [  426.884702] (es-start)[2816]: acme-lockfiles.service: Changing to the requested working directory failed: Permission denied
webserver # [  426.934208] (es-start)[2816]: acme-lockfiles.service: Failed at step CHDIR spawning /nix/store/n24xs3nmndyyivq3q5w52f7aqlb06hqh-unit-script-acme-lockfiles-start/bin/acme-lockfiles-start: Permission denied

In reply to @k900:0upti.me
Or the units need to also wants the server

An idea for fixing this: I could add more targets in the ACME module to simplify the config and dependencies in the webserver + other downstream modules, and potentially help resolve this issue also:

• Add an acme-renewal-http01.target which requires and after the relevant acme services.
• For each web server listening on port 80 or configured to serve the acme-challenge directory (either is possible and logic already exists to discover these cases), add a requires and before rule on acme-renewal-http01.target

Honestly, I'm trying to think of reasons I haven't done this until now. I could add targets for other renewal types with the intention to allow DNS server startups in the same way. I could even go further and add targets for acme-selfsigned.target and acme-renewal.target so that downstream services generally don't need to worry about what certs to wait on. I would hazard a guess that the complement of certs being waited on is significant in 90% of system configurations out there, and using these general targets wouldn't cause much more slow down.

In reply to @k900:0upti.me
Or the units need to also wants the server

An idea for fixing this: I could add more targets in the ACME module to simplify the config and dependencies in the webserver + other downstream modules, and potentially help resolve this issue also:

• Add an acme-renewal-http01.target which requires and after the relevant acme services.
• For each web server listening on port 80 or configured to serve the acme-challenge directory (either is possible and logic already exists to discover these cases), add a requires and before rule on acme-renewal-http01.target

Honestly, I'm trying to think of reasons I haven't done this until now. I could add targets for other renewal types with the intention to allow DNS server startups in the same way. I could even go further and add targets for acme-selfsigned.target and acme-renewal.target so that downstream services generally don't need to worry about what certs to wait on. I would hazard a guess that the complement of certs being waited on is not significant in 90% of system configurations out there, and using these general targets wouldn't cause much more slow down.

In reply to @m1cr0man:m1cr0man.com
Just looking over the maxConcurrentRenewals implementation, and the options/discussion from last year. I'm really starting to feel that the systemd dependency approach would have been more straightforward. I couldn't convince folks at the time, and there was lengthly discussion in which it really needed feedback from another maintainer. I went with the current solution because I felt there wasn't much between them and that it may lend to more ACME contributors, but I'm seeing now that it's a heavy bit of complexity and we're still limited on maintainers.