Closed tedgarb closed 1 month ago
What I never understood was why in v6.6.0
https://github.com/voxpupuli/puppet-systemd/blob/v6.6.0/manifests/service_limits.pp
this had a hardcoded notify_service => true,
v7 copied the behaviour of v6.6.0.
Looks like you can blame me for https://github.com/voxpupuli/puppet-systemd/commit/8a9e03a4d6a58a5a5083d7ead60dcbc87f727d2f. It's been present since version 4.0.0.
I'm not sure if it is inherently bad behavior, especially given the bit in #406 that would have meant making it toggle-able would not have had the expected effect. Perhaps something to parameterize in 7.x. I'm happy to work on a PR to make it adjustable, assuming #406 gets processed in some form.
Changing it to default to false would nominally fix the problem in my original issue, but would be a new change in behavior that seems ill-advised outside a major version.
It feels to me that this is a bit of an edge case. The service limits are deprecated so I'm not sure if we shouldn't just encourage users to migrate away from it, like you did.
While I agree the restart parameter discussion is somewhat moot given the deprecation, I do not think this should derail the higher order problem, which is that 7.0.0, in addition to introducing a deprecation warning, causes in situations like the above services to restart unexpectedly, with no way to preemptively detect this short of auditing and validating your entire site's configuration tree and proactively modifying the declarations. Since this issue seems to be caused most directly by the switch inside 988d2c7 from systemd::dropin_file
to systemd::manage_dropin
when providing limits via the limits
parameter, I would request that narrow part of the broader commit be reverted, in the absence of a more natural way to prevent unexpected restarts. I don't see an obvious way to change the behavior of systemd::manage_dropin
to prevent restarts for people using that already, so the obvious path to me is to switch back to the 6.6.0 method for generating the dropin file within systemd::service_limits
. I understand that this would involve either reinstating the erb template or writing a new one in epp, but it would be a lot easier for me and I am sure other users if there was a path from 6.6.0 to 7.x that allowed us to simply catch and post-fix the deprecation alerts, rather than having to preemptively analyze our entire sites.
Thinking about this a bit further, I do not actually think telling users to switch from service_limits
to dropin_file
is really an equivalent experience, because the parameterized hash that service_limits
provides plays nicely with hiera and the hierarchical nature of parameters, and dropin_file
really just wants string content. I think what I will be doing personally is waiting for #406 to get released, and then forcing my puppet userbase to migrate their service_limits
to manage_dropin
before I switch the module we offer to 7.x, giving them the option to control if and when their services restart.
The only thing I could see to ease the transition and provide obvious before/after guidance would be to make service_limits::restart_service
propagate, but I see some obvious potential risks in making the false
value change behavior within 7.x for some use cases, so I'm not going to actually say that should be considered.
I would like to humbly request a more explicit warning be added to the 7.x release notes warning that users of service_limits
may see units restart as a result of upgrading the systemd module, and possibly some better notes based on this ticket about what can be done to prevent it, especially once preventing it does not require disabling daemon_reload as it does in 7.0.0
With 406 merged and the readme providing more explicit instructions on how to prep for this, the about-to-be-released 7.1.0 version would have been enough for me to avoid having to open this issue, so I'm closing it out. Thanks for listening to me ramble :)
Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce (e.g Puppet code you use)
The simplest example I have is this, from a profile I use to manage oracle database services for our DBA team:
What are you seeing
When I set up an environment that bumps this module from 6.6.0 to 7.0.0, the file
/etc/systemd/system/oracle.service.d/90-limits.conf
is reordered, seemingly due to the switch from an erb template being processed and then shoved into asystemd::dropin_file
to being sent to asystemd::manage_dropin
. This on its own is annoying, but not a critical issue. However, because manifests/service_limits.pp setsnotify_service => true
inside thesystemd::manage_dropin
with no mechanism to override it, the service would be restarted if I allowed this to apply.What behaviour did you expect instead
I would expect that the service would not be restarted due to a module version upgrade.
Output log
(there are several other affected units that are the same structure as the above snippet):
Any additional information you'd like to impart
In an attempt to front-run the deprecation warning, I attempted simply proactively replacing the
systemd::service_limits
declaration with asystemd::manage_dropin
one, as the deprecation warning suggests, and manually changingnotify_service => false
, but #406 means this does not work without also settingdaemon_reload => false
, which is not an optimal solution as it leads to the need to manually rundaemon_reload
on these hosts if the file changes in the future.Specifically, this causes a restart:
And this does not: