-
-
Notifications
You must be signed in to change notification settings - Fork 92
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
version 4 doesn't obey manage_cron_daily parameter #161
Comments
Same for us. We explicitly chose to set This change was introduced in #137 I tend to revert this change. @cliff-wakefield as author of the PR and @bastelfreak and @dhollinger as reviewer, could you please let us know your opinion on this? :) |
This is unexpected behavior we noticed as well. We wanted the Logrotate module to leave the file alone but the module decided instead to remove it. The expected behavior of |
While I don't fully agree I can see why you may want to split ensure_ and manage_ intentions, but it does create confusion. The intent of the original PR was to allow cron entries for daily and hourly to be managed outside of the module. Such that you could override the OS defaults for the exact time daily and hourly entries executed. If we split the manage_ and ensure_ we need to know the desired behaviour.
So with that logic, it doesn't work. I think
Thoughts @bastelfreak , @dhollinger ? |
I've also hit this and would prefer |
In version 4 when manage_cron_daily is set to false module removes /etc/cron.daily/logrotate
That's managing the file, isn't it? I think this behavior is improper, resource should be left alone for user to handle
The text was updated successfully, but these errors were encountered: