F15 Feature - convert as many service init files as possible to the native SystemD services
mzerqung at 0pointer.de
Fri Nov 26 00:51:57 UTC 2010
On Fri, 26.11.10 00:46, Andrew Clayton (andrew at digital-domain.net) wrote:
> On Fri, 26 Nov 2010 01:15:04 +0100, Lennart Poettering wrote:
> > The only contents of /etc/crontab and /etc/cron.d is the lines to
> > handle /etc/cron.daily and friends. As mentioned we can easily run
> On RHEL/CentOS (and it's likely only a matter of time before systemd
> fillers through to them) various programs install jobs into /etc/cron.d
> a quick look on one machine shows; mailman and sysstat related jobs as
> well as some others...
> > those as normal timer-triggerd units inside of systemd itself (and
> > get all the features it offers you for free, nice introspection,
> > logging, IO/CPU scheduling hooks, yadda yadda). So, if you remove
> > that /etc/crontab is empty and hence could be removed.
> > And /etc/cron.d is empty too. And there you go, we can support cron
> Although I can't be the only one who puts various cron jobs
> under /etc/cron.d that get run at various times.
Yes, of course, people use those dirs. But by default they are
empty. And by using the systemd .path units we can make cron start the
moment somebody (or rpm) drops something into those dirs.
So, cron continues to work how it always worked! But the laptop
population won't have to run crond or at anymore. But they can still use
it, and it will just work, because the daemons are started the moment
they are needed.
So, drop your defensive reflexes: I am not taking anything away from
you. Just minimizing what we start in the default case.
Lennart Poettering - Red Hat, Inc.
More information about the devel