Hi,
On Mon, 5 May 2014 08:05:08 -0500
Maciej Puzio <mx34567@xxxxxxxxx> 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.
AFAIU systemd is supposed to start timers "randomly" in the time interval
[1d, 1d + 12h]; different timers are started in parallel. Are you arguing that
the starting time is not "random" enough?
>
> 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.
You misunderstood the point here.
Systemd timers (at least in the current form) are _not_ cron replacement.
However, they are adequate for daily maintainance jobs that are shipped with
packages. If you had custom, carefully scheduled cron jobs, you should
continue using cronie. What I don't understand is why do you care when
man-db/updatedb runs?
>
> 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.
The scripts mainly set up the environment which is now done by systemd. You
issue is with scheduling, and it will _not_ go away because scripts are still
executed by systemd (as opposed to cronie).
Cheers,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Attachment:
signature.asc
Description: PGP signature
