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

Inconsistent values for notify_service in replacement for systemd::service_limits #481

Open
johnwarburton opened this issue Jul 23, 2024 · 1 comment

Comments

@johnwarburton
Copy link

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: 7.25.0
  • Ruby: 2.7.8p225 (2023-03-30 revision 1f4d455848) [x86_64-linux]
  • Distribution: Rocky Linux release 9.2 (Blue Onyx)
  • Module version: 7.1.0

How to reproduce (e.g Puppet code you use)

The deprecation notice states:

The type systemd::service_limits is deprecated and systemd::manage_dropin or systemd::dropin_file should be used instead.

What are you seeing

Wanting to set LimitNOFILE with the puppet-systemd module, I read the deprecation notice and used systemd::dropin_file as we already have a working example. The limit was set correctly for the service, but on re-review of the module code, I felt using systemd::manage_dropin would be less error prone

When using service_entry in systemd::manage_dropin, the dropin file was correctly created but the service did not have its limit changed. I had to add notify_service: true for the service to be restarted and set the limit correctly

What behaviour did you expect instead

Given the deprecation notice and systemd::manage_dropin or systemd::dropin_file are offered as equal alternatives, I would expect both types to have the same defaults for notify_service, whereas we have different defaults

$ egrep -r 'Boolean.*notify_service' manifests/
manifests/manage_dropin.pp:  Boolean                          $notify_service          = false,
manifests/dropin_file.pp:  Boolean                                     $notify_service          = true,

Any additional information you'd like to impart

I am guessing some of this came from the work in #463
Also, I am well aware I could be told to RTFM, which I ended up doing, but in the spirit of the principle of least surprise and people who come after me, it would be nice to have a consistent default for notify_service (and IMHO, that would be true)

Thanks for such a great module, always appreciate your work

@smortex
Copy link
Member

smortex commented Jul 25, 2024

+1 for consistent behavior. IMHO, the default should be to restart what has to be restarted, and offer the possibility to opt-out from restarting services if needed be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants