Nixpkgs: service dhparams-init fails

[rnhmjoj]

Issue description

$ systemctl status dhparams-init.service
dhparams-init.service - Cleanup old Diffie-Hellman parameters
   Loaded: loaded (/nix/store/gkkk38lk3pmym1c02nphapcswp1grhz3-unit-dhparams-init.service/dhparams-init.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2017-03-05 04:58:04 CET; 9min ago
  Process: 3312 ExecStart=/nix/store/n2dxh3vsfjqkdhg81fkdr7p0ykpp6bk9-unit-script/bin/dhparams-init-start (code=exited, status=1/FAILURE)
 Main PID: 3312 (code=exited, status=1/FAILURE)

$ journalctl -u dhparams-init.service
Mar 05 04:58:04 maxwell systemd[1]: Starting Cleanup old Diffie-Hellman parameters...
Mar 05 04:58:04 maxwell dhparams-init-start[3312]: rmdir: failed to remove directory '/var/lib'
Mar 05 04:58:04 maxwell systemd[1]: dhparams-init.service: Main process exited, code=exited, status=1/FAILURE

Also, and more importantly, why is it trying to remove /var/lib?

Steps to reproduce

I upgraded the system to latest unstable: i'm not sure why it gets started and what it's supposed to do.
Possibly because I have nginx with TLS enabled?

Technical details

• System: 17.09 6011e3e
• Nix version: 1.11.7

[rnhmjoj]

22634

[grahamc]

cc @fpletz

[Nekroze]

I am also getting this issue having switched to the 17.03 beta channel. I have no services that require a dhparam on the machine from what I can see. It just fails on attempting to delete /var/lib which is a bit scary.

EDIT: I am not having this issue on a different machine, the primary difference between them is that the machine it is happening on has a partition mounted on /var/lib.

[rnhmjoj]

The service should be disabled unless security.dhparams is non-empty imho. I don't understand the part

rmdir -p --ignore-fail-on-non-empty ${cfg.path}

[fpletz]

cc @Ekleog

[Ekleog]

This line just removes all empty directories in ${cfg.path}, that's required to be enabled on every system in order to clean up after removing all elements from security.dhparams and achieve actual reproducibility (leaving empty directories would be leaving state that should not be present if dhparams hadn't been added beforehand).

As ${cfg.path} can be configured, it's not possible to just put an exception for /var/lib, but it never being empty protects it from being removed.

That said, it's weird it causes a FAILURE, as -p --ignore-fail-on-non-empty is specifically designed to allow removing all empty directories, not failing on a non-empty directory. I guess it doesn't correctly handle the case of trying to remove a mounted directory, as trying it with mkdir /tmp/foo && rmdir -p --ignore-fail-on-non-empty /tmp/foo causes the same issue for me.

It's possible to remove this line (which doesn't have perfect reproducibility anyway, as it doesn't handle the case of someone changing the cfg.path between two activations), that would leave an empty directory /var/lib/dhparams on the machine which added then removed dhparams. Another solution is to just add > /dev/null 2>&1 || true, as it's not actually dangerous (to the best of my knowledge) and is just plain scary for no real reason (no non-empty directory can be removed by rmdir)

What do you think about these options?

[rnhmjoj]

I would go with just removing it. Anyway I don't think the service should be running if the option is not being used.

[joachifm]

A workaround for those of us who don't care for dhparams is to do

systemd.services.dhparams-init.enable = false;