Service unit: only run if /var/log is mounted and timer trigger fuzz from 12h to 1h#230
Service unit: only run if /var/log is mounted and timer trigger fuzz from 12h to 1h#230aledomu wants to merge 2 commits intologrotate:masterfrom aledomu:patch-1
Conversation
Given that `Persistent=true` can cause a timer to fire during the boot of the system if the timer would have expired while the system was shut off, the service should ensure that `/var/log` is mounted (could be a network filesystem).
|
Looks good to me! What about the other suggestion at https://src.fedoraproject.org/rpms/logrotate/pull-request/1 ? Should we override the default 12h is IMO way too big fuzz for daily rotations... |
|
My biggest concern is if any distribution takes this file for its packages and it expects this value for some reason. If that's not the case (which I would say it isn't, but don't take my word on it) or it turns out it is a non-issue then I'm fine with whatever value you think is more appropriate. Some food for thought: the reason for this parameter to exist is to run multiple tasks at the same time to avoid multiple scattered CPU wake-ups (in order to optimize power usage). This means that if the system is constantly running stuff (servers, which is where syslog + logrotate is mostly used nowadays) changing this parameter won't make a big difference. However, for desktop/laptop systems, it will (if the user chooses to completely avoid the journal). My rationale is that given that logrotate is not CPU-intensive at all (if anything, I/O intensive), increasing this delay margin makes little to no impact on power consumption in a laptop. For servers, it seems to me that it makes no difference in behaviour at all in most cases (haven't tested it though). So I would not change the value; I would drop it entirely (the default is 1 min). I don't have a particular interest on doing it this way, so I'm fine if it's left unchanged or another value is chosen. Just giving my 0.02 cents. Let me know what you think. |
|
On Tuesday, November 27, 2018 8:16:28 PM CET Alejandro Domínguez wrote:
My biggest concern is if any distribution takes this file for its packages
and it expects this value for some reason.
It is unlikely that someone relies on the fact that rotations are triggered
at a random time within 12 hours window.
If that's not the case (which I
would say it isn't, but don't take my word on it) or it turns out it is a
non-issue then I'm fine with whatever value you think is more appropriate.
Could something like 1 hour be a fair trade-off?
Some food for thought: the reason for this parameter to exist is to run
multiple tasks at the same time to avoid multiple scattered CPU wake-ups
(in order to optimize power usage). This means that if the system is
constantly running stuff (servers, which is where syslog + logrotate is
mostly used nowadays) changing this parameter won't make a big difference.
However, for desktop/laptop systems, it will (if the user chooses to
completely avoid the journal).
Yes, that is what the documentation says. But I suspect that it only matters
in case you set 1 sec vs 1 usec. I do not think that 12 hours vs 1 hour will
make any measurable difference in the number of CPU wake-ups.
My rationale is that given that logrotate is not CPU-intensive at all (if
anything, I/O intensive), increasing this delay margin makes little to no
impact on power consumption in a laptop. For servers, it seems to me that
it makes no difference in behaviour at all in most cases (haven't tested it
though). So I would not change the value; I would drop it entirely (the
default is 1 min). I don't have a particular interest on doing it this way,
so I'm fine if it's left unchanged or another value is chosen. Just giving
my 0.02 cents.
I think that the original motivation for triggering daily jobs with 12 hours
fuzz was to distribute the load on remote servers, e.g. when synchronising
package metadata on a big number of nodes.
Let me know what you think.
I think that 12 hours fuzz is just too much but I am not going to block this
pull request because of it as it can be tweaked separately.
|
Seems fine to me. There goes another commit. |
|
Thanks for the contribution! Merging... |
The initial introduction of the systemd timer in commit 05228c2 ("Add logrotate service and timer for systemd") included the directive `AccuracySec=12h`. AccuracySec= is not a load distribution option but a power saving one, see systemd-timer(5). In commit 3f3991e ("Timer unit: change trigger fuzz from 12h to 1h") the value was reduced to 1h, while the discussion in logrotate#230 also mentioned load distribution. Use RandomizedDelaySec= instead of AccuracySec= to actually spread the start time of the service, and ignore potential system wakeups below the rate of the default of AccuracySec= of one minute. Fixes: logrotate#567
The initial introduction of the systemd timer in commit 05228c2 ("Add logrotate service and timer for systemd") included the directive `AccuracySec=12h`. AccuracySec= is not a load distribution option but a power saving one, see systemd-timer(5). In commit 3f3991e ("Timer unit: change trigger fuzz from 12h to 1h") the value was reduced to 1h, while the discussion in logrotate#230 also mentioned load distribution. Use RandomizedDelaySec= instead of AccuracySec= to actually spread the start time of the service, and ignore potential system wakeups below the rate of the default of AccuracySec= of one minute. Fixes: logrotate#567
The initial introduction of the systemd timer in commit 05228c2 ("Add logrotate service and timer for systemd") included the directive `AccuracySec=12h`. AccuracySec= is not a load distribution option but a power saving one, see systemd-timer(5). In commit 3f3991e ("Timer unit: change trigger fuzz from 12h to 1h") the value was reduced to 1h, while the discussion in #230 also mentioned load distribution. Use RandomizedDelaySec= instead of AccuracySec= to actually spread the start time of the service, and ignore potential system wakeups below the rate of the default of AccuracySec= of one minute. Fixes: #567
Given that
Persistent=truecan cause a timer to fire during the boot of the system if the timer would have expired while the system was shut off, the service should ensure that/var/logis mounted (could be a network filesystem).