[arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

[Leonid Isaev]

On Fri, 25 Apr 2014 17:19:04 -0400
Carl Schaefer <schaefer at trilug.org> wrote:

> 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).

But then again, you don't maintain the cron package...

> 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...

> 
> 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,

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

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

So far, I have seen only (minor) inconveniences associated with switching to
the timers, which essentially have to do with system(d) startup time. Notice
that these issues will not be visible on servers because there systemd's
parallellization of the boot process is irrelevant.

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

> 
> 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?

Ask this on [systemd-devel].

Cheers,
L.

-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
                  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140425/52122954/attachment.asc>