On 05/05/14 09:05 AM, Maciej Puzio wrote: > I have been testing the issue for a week. Daily timers are fired > between 0:00 and 0:01 without exception - all timers at the same time, > all machines at the same time, every day at the same time. The largest > variation I have seen was 30 seconds. So yes, there is definitely an > issue with AccuracySec=12h not being honored. > > However, whether timer accuracy is 30 seconds or 12 hours, this makes > little difference to me, as both are unacceptable without the > possibility to customize timer elapse time. I have reverted all my > Arch machines to previous cron-based config and intend to keep it this > way. Perhaps it is not "cool", but at least it works. > > Which brings me to what I consider the most important problem here. > Having read the original thread on arch-dev-public I was left with an > impression that perceived "coolness" of the new setup took precedence > over consideration of its impact. As a result, modification has been > released without sufficient testing, as we can clearly see now. It did > not help that discussion was carried on a mailing list that does not > allow user comments. Perhaps a larger audience would have allowed a > consideration of alternative solutions. An example of such a solution > would be hourly/daily/monthly/weekly timers that execute scripts from > relevant /etc/cron.* directories. That would allow for removal of > cronie while sidestepping timer elapse problems that we are discussing > here. It would also have a benefit of handling all cron tasks in > addition to logrotate/updatedb/man-db/shadow. > > Thanks > Maciej Puzio
cronie was not enabled by default before and these systemd timers are, so there has been an improvement in the default configuration. The issue of systemd not spreading out the timers enough can be fixed, because if true it's a bug.
signature.asc
Description: OpenPGP digital signature
