F15 Feature - convert as many service init files as possible to the native SystemD services

Lennart Poettering mzerqung at 0pointer.de
Fri Nov 26 00:27:21 UTC 2010

On Thu, 25.11.10 17:33, Tomas Mraz (tmraz at redhat.com) wrote:

> > Actually it's true, but in the near future all standard cron jobs
> > might be runned by systemd
> > 
> > http://0pointer.de/public/systemd-man/systemd.timer.html
> > 
> > It's not 100 % cron replacement now, but who knows what the future holds :)
> To add some argument to my previous sarcasm. I do not think that it
> makes any sense to replicate cron functionality in systemd. Either you
> replicate half of it and then you still need to run crond for the rest
> or you replicate it completely. But in that case what is the saving over
> the separate daemon? I'm sorry but I do not think that crond is anything
> that "optimized out" by inclusion can improve performance of Linux
> desktop/server/whatever. I do not say that cronie code cannot be
> improved - it definitely can - but it does not make any sense to
> reimplement it from scratch.

crond is not particularly complex. And providing similar functionality
in systemd is relatively easy as the more complicated stuff cron does is
actually spawning the processes, and systemd is vastly more powerful
with that. i.e. you can set IO/CPU schedulers, get sane logging, get all
the cgroups niftyness, you can pull in extra deps, yadda yadda.

Also, what's particularly interesting is that you can combine various
triggers if you do this in systemd: i.e. have one timer-based trigger,
and one inotify trigger (i.e. .path unit), and they start the same job,
and you don't end up with duplicates and need locking. 

And also, cron does a couple of really nasty things. For example it
wakes up in regular intervals to check if a job is ready to run. It does
so to deal with wallclock time changes/suspends. In systemd we are
working on a different way to solve this, so that we can actually sleep
as long as possible, and don't have to wake up in regular
intervals. Also, this means we can have much more accurate time
specifications, and we don't have to pay a price for it, due to
this. This different design will even allow us to do amazing stuff that
hasn't existed so far, for example, mark cron jobs so that they wake up
the machine from suspend, and similar.

To summarize this: the current logic of cron is not pretty. And it
duplicates process spawning and babysitting which already exists in way
too many daemons, and is actually the more interesting code. systemd
unifies all that code, and the end result will be simpler, more powerful
and less code, since we reuse what already exists anyway. The only thing
we basically add to systemd is a parser for calendar events, and
everything else already exists.


Lennart Poettering - Red Hat, Inc.

More information about the devel mailing list