Skip to content
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

nixos/systemd: add StartLimitIntervalSec to unit config #50849

Merged
merged 1 commit into from Jan 28, 2019

Conversation

cyounkins
Copy link
Contributor

@cyounkins cyounkins commented Nov 20, 2018

Motivation for this change

Adds the new attribute to configure unit start rate limiting.
Documentation: https://www.freedesktop.org/software/systemd/man/systemd.unit.html
Ref #45785

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

@@ -210,6 +210,16 @@ in rec {
'';
};

startLimitIntervalSec = mkOption {
default = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably shouldn't have a default.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand. When default is set as it is here, the attribute is not written out to the systemd unit file. Why it isn't written isn't quite clear to me.

If I remove the default = 0; line, I get The option systemd.services.audit.startLimitIntervalSec' is used but not defined.` for all services.

@@ -219,7 +219,9 @@ let
// optionalAttrs (config.documentation != []) {
Documentation = toString config.documentation; }
// optionalAttrs (config.onFailure != []) {
OnFailure = toString config.onFailure;
OnFailure = toString config.onFailure; }
// optionalAttrs (config.startLimitIntervalSec != []) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the default, add an options argument at line 196, then change this here to options.startLimitIntervalSec.isDefined

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! It looks like the comparisons at

optionalAttrs (config.requires != [])
are against their defaults. Should they be changed to use isDefined?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually not sure now what would be better

Property Comparing with default Using isDefined Importance (subjective)
Defining as default doesn't trigger generation Yes No 2
Is usually done Yes No 5
Can use value without having set it (getting an empty list makes sense and is useful) Yes No 10
No need to duplicate upstream defaults No Yes 10
Reflects the fact that set values have an influence, unset ones don't No Yes 3

Both have advantages and disadvantages. Assigning some subjective importances to these properties, it's 17 vs. 13. The fact that we don't need to duplicate upstream defaults is a pretty good seller for me, but this also means we can't use these config values without having set them, which can be very useful.

After this consideration, I think it would be better to compare everything with the default value instead, so you could change it back again to the original way and use the upstream default is the options default. Now maybe other people have different opinions, but this is mine :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@grahamc Could we get your opinion?

@infinisil You seem to suggest that "Defining as default doesn't trigger generation" is a good thing - I would say the opposite. If I explicitly and concretely specify a parameter (eg 0), I would want it written to the config file even if it matches the default. Without the intermediate nix layer, I would have explicitly written it to the config myself.

If I explicitly and abstractly specify the parameter as default, I don't have a strong opinion on if it should be written to the config. I could go either way.

I guess that's a major part of Nix that perhaps needs more documentation. It aims to be the configuration of all configurations, a superset of all others, and we should be consistent on how we handle different styles of configuration.

Could you elaborate on your thinking when you say "Can use value without having set it (getting an empty list makes sense and is useful)" - While getting an empty list makes sense, I don't see how it's useful if nothing is written out. I guess you mean that you can use the variable the same way whether or not it was specified instead of conditioning on isDefined?

@rasendubi
Copy link
Member

(triage) @infinisil is PR good to go now?

@rasendubi
Copy link
Member

(triage) @grahamc could you chime in?

@infinisil
Copy link
Member

Actually, why do we need this option at all? Users can just set serviceConfig.StartLimitIntervalSec

@cyounkins
Copy link
Contributor Author

@infinisil can you elaborate? I see two references to StartLimitIntervalSec in the repo, but do those actually work? I don't have access to my test box right now. I thought all the unit configuration options needed to be enumerated in nixos/modules/system/boot/systemd-unit-options.nix for them to be usable.

This commit also adds the documentation in line with all the other unit configuration options.

Copy link
Member

@infinisil infinisil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sorry you're right, I actually didn't know that, but it makes sense looking at the code.

@infinisil
Copy link
Member

Only thing left to do is squash the commits into one. The isDefined thing should be fine.

@cyounkins
Copy link
Contributor Author

You can squash in the GitHub UI right? Or do you need me to squash them?

@infinisil
Copy link
Member

I prefer the PR owners to do the squash. This keeps potential signatures intact, makes the PR have the same commit hash as the merged commit, and it lets the PR author write a suitable combined commit message.

@cyounkins
Copy link
Contributor Author

@infinisil Done!

@infinisil infinisil merged commit 2a40236 into NixOS:master Jan 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants