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

Marcela Mašláňová mmaslano at redhat.com
Fri Nov 26 06:42:15 UTC 2010

On 11/26/2010 01:27 AM, Lennart Poettering wrote:
> 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.
Cronie is using inotify, so it doesn't wake every minute as it used to.

I'm just curious, how many programmes would stay in Fedora after
you finish systemd ;-) </sarcasm>.


Marcela Mašláňová
BaseOS team Brno

More information about the devel mailing list