It seems to me that, compared to cron/anacron, systemd timers currently offer reduced functionality and no clear benefit (I don't consider the act of uninstalling cron to have significant value in itself). Losing the ability to control when jobs run is giving up a lot; without that, the more use is made of systemd timers, the more unpredictable the results will be. Perhaps I'm missing something, because I don't fully understand all the points Thomas raised last month in his proposal on arch-dev-public:

Pros: * enabled by default (in contrast to cronie) * systems without need for crontabs can disable/uninstall cron * service will be simpler than the rather long dropin scripts

Cons: * services are run in parallel instead of sequentially (is this even a con? timer start will be randomized, and we can increase accuracy to an hour to randomize even more) * no holdoff time after boot as it seems

pro#3 is a mystery to me, and missing from the "con" list is the point Maciej raised about the effect random timer jobs can have on busy servers. If this ship is already sailing, though, the goal should be to add functionality to systemd timers so that it becomes a real replacement for cron, e.g. allow execution windows to be defined, jobs placed within these windows, and scheduling parameters like acceptable degrees of parallelism to be specified. Something like that could be more powerful and flexible than cron, and potentially easier to manage than a set of crontabs. Does anyone know if the systemd timers roadmap includes anything like this? Carl

...

Losing the ability to control when jobs run is giving up a lot; without that, the more use is made of systemd timers, the more unpredictable the results will be.

See systemd.timer(5) manpage. The timer configuration _should be_ one-to-one equivalent to a crontab, except for a different syntax...

thanks, the description of the OnCalendar syntax is actually in systemd.time(7), and I'd missed it. It does look like an improvement over the crontab file syntax in readability, at least.

...

...

* service will be simpler than the rather long dropin scripts

Just compare {man-db,logrotate,updatedb}.service files with the corresponding scripts in cron.daily...

if there's a complex script in cron.daily, I'd expect the service file would have to invoke a similar script to do the same work.

...

and missing from the "con" list is the point Maciej raised about the effect random timer jobs can have on busy servers.

The timer jobs are niced to 19 so if the server is busy they should wait, no?

that sounds like a reasonable assumption, but based on the problem report it may not be true. thanks! Carl

On 05-05-14 15:05, Maciej Puzio wrote:

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 That sounds like a good idea. Instead of removing the entire cron system, this would allow systemd-timers to function as an alternative to cron. it would also reduce the increasing dependency archlinux has on systemd as init system.

Lone_Wolf

Hi, On Mon, 5 May 2014 08:05:08 -0500 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.

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

On Tue, 6 May 2014 13:23:26 -0500 Maciej Puzio wrote:

As I wrote before, I can edit every timer file and set the elapse time. What I can't do is to change one setting which says when daily maintenance tasks are run. This was possible with cron, but is no longer possible now. What's the problem to edit four files? Well, this is multiplied by the number of machines that are under my care. Again, here is relevant systemd RFE link: https://bugs.freedesktop.org/show_bug.cgi?id=77938

This is bogus. See "man 7 systemd.time"; what you want is something like "OnCalendar=*-*-* 04:10:20" for a job that runs every day at 4:10:20 AM.

On Mon, May 5, 2014 at 12:21 PM, Leonid Isaev wrote:

...

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?

After re-reading the documentation I have to take this back, systemd timers seem to implement all features provided by 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

(Tue, May 06, 2014 at 04:28:48PM -0400) Daniel Micay :

On 06/05/14 04:13 PM, Leonid Isaev wrote:

...

After re-reading the documentation I have to take this back, systemd timers seem to implement all features provided by cronie.

AFAIK, the only notable missing feature is the ability for non-root users to run jobs when they're not logged in. This is intentionally left out, and it's not hard for an administrator to replicate the feature with a timer unit for a specific user allowed to run jobs.

Note that loginctl enable-linger <user> launches the systemd of <user> even when he is not there -- Ismael

Hi, On Wed, 7 May 2014 13:34:29 -0500 Maciej Puzio wrote:

On Tue, May 6, 2014 at 3:13 PM, Leonid Isaev wrote:

...

On Tue, 6 May 2014 13:23:26 -0500 Maciej Puzio wrote:

...

As I wrote before, I can edit every timer file and set the elapse time. What I can't do is to change one setting which says when daily maintenance tasks are run. This was possible with cron, but is no

You mean, you could change /etc/anacrontab?

...

...

longer possible now. What's the problem to edit four files? Well, this is multiplied by the number of machines that are under my care.

Why can't you put additional configs in /etc/systemd/system/xxx.timer.d/ dir?

...

...

Again, here is relevant systemd RFE link: https://bugs.freedesktop.org/show_bug.cgi?id=77938

This is bogus.

Leonid, please reread the above paragraph and my previous posts, with comprehension. With all due respect, your replies are not related to the issue discussed.

It is completely unclear what you want to be fixed and the title is misleading... If you have machines m_1 ... m_N and want to spread the anacron jobs, you need to edit N anacrontabs, right? Now you need to do k*N changes, k -- the number of jobs used to be started by anacron. Are you asking for a centralized control affecting all "daily" timers like the per-machine anacrontab? If true, this is unlikely to be implemented (at least I wouldn't do it). Perhaps a proper approach is to create a special target for your maintainance jobs which would pull all relevant services and would itself be triggered by an OnCalendar timer. Although I am not sure whether a timer can directly trigger a target yet... 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

On Thu, 8 May 2014 14:24:45 +0900 Savyasachee Jha wrote:

On Thu, May 8, 2014 at 6:23 AM, Leonid Isaev wrote:

...

Perhaps a proper approach is to create a special target for your maintainance jobs which would pull all relevant services and would itself be triggered by an OnCalendar timer. Although I am not sure whether a timer can directly trigger a target yet...

They can, do refer to https://wiki.archlinux.org/index.php/Systemd/cron_functionality where you can find some examples of the same.

Cool. I didn't know about that wikipage. Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

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.