-
-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
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
acme service fails at step NAMESPACE spawning #103121
Comments
ping @NixOS/systemd (edit: actually @NixOS/acme might be more appropriate maybe) |
Is this the first acme run (on this box / for this domain) or simply a new run on the new commit for already existing certificates? |
The certificates already existed. But I think this might have been the first run since switching to the new module. Edit: I have since gotten working certs again by running the script manually (with some hacks). But the unit is still broken and will fail to renew my certs in the future. |
If you still have state from the old module in /var/lib/acme you could try to move it somwhere else, re-run the system activation script and see if that unbreaks the services. |
If you can reliably reproduce; could you type:
to enable debug logging And see if the systemd logs on activation tell you more why it fails to set up the namespace? Please share the resulting logs here. For completions' sake; are you running any custom kernel, and/or custom kernel commandline arguments that could influence systemd? e.g. cgroupsv2 enabled or not |
In my experience, this error message means that one of the directories mentioned in the systemd unit does not exist. Did you run systemd-tmpfiles --create ? |
@symphorien |
Also see #97702 (comment) for a slighly more verbose rant ;-) |
I am getting the same error and running the Here is a log. The root cause seems to be trying to read the
BTW here is the relevant ACME configuration:
|
I can't see anything here that relates this particular failure directly to the acme module. My only assumption right now would be that something in systemd is failing to apply the systemd.services."example.org".serviceConfig.ProtectSystem = lib.mkForce false; |
Thanks, I tried it: diff --git a/machines/localhost/nixos/configuration.nix b/machines/localhost/nixos/configuration.nix
index f872df8..9d65010 100644
--- a/machines/localhost/nixos/configuration.nix
+++ b/machines/localhost/nixos/configuration.nix
@@ -1,4 +1,4 @@
-{ config, pkgs, ... }:
+{ config, pkgs, lib, ... }:
{
imports =
[
@@ -207,6 +207,7 @@
};
systemd.services.nginx.serviceConfig.ProtectHome = "read-only";
+ systemd.services."acme-example.org".serviceConfig.ProtectSystem = (lib.mkForce false);
time.timeZone = "America/New_York"; but the error persists:
|
Can you try running |
Thank you @m1cr0man, I did try running the commands as well as setting
I pasted the version of |
@m1cr0man That fixed it for me! There was an error the first run because LetsEncrypt was busy, but it worked during the second run:
|
Amazing! Wrt the first failure, are you by chance running a DNS server locally too? |
I am, just Is the reason it failed the first time because the propagation check failed? |
Yeah so there's a known issue where if your local resolver is used in your resolv.conf then the acme module may fail on a rebuild because it starts before your DNS server. I get the same error (or a similar one) on my system which runs Bind. The fix theoretically involves some sort of generalised ability for the ACME module to wait for a local DNS server to come online, and we haven't figured that out yet ;) but it will be done soon. I'll open a real ticket for it now. |
Describe the bug
When trying to run my acme service, I get this systemd error. My nixpkgs in currently following the
unstable
channel, on this commit:34ad166a830d3ac1541dcce571c52231f2f0865a
A cat of the unit that gets generated
The full log for the unit:
Additional context
I don't know if this is an acme module issue, or if it's a general systemd issue that only manifests itself in this module. I'm also not sure if the
accounts
file it fails on has actually ever existed.The text was updated successfully, but these errors were encountered: