F15 Feature - convert as many service init files as possible to the native SystemD services
tmraz at redhat.com
Thu Nov 25 16:33:32 UTC 2010
On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote:
> 2010/11/25 Tomas Mraz <tmraz at redhat.com>:
> > On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote:
> >> That's the point of the .path unit. i.e. you can list dirs to watch. If
> >> a user then drop a file into one of those dirs cron gets automatically
> >> started.
> >> Basically, in your .path unit you'd write something like this:
> >> [Path]
> >> PathExists=/etc/crontab
> >> DirectoryNotEmpty=/etc/cron.d
> >> DirectoryNotEmpty=/var/spool/cron
> >> And the moment where /etc/crontab starts to exist, or somebody drops a
> >> file into /etc/cron.d or /var/spool/cron crond would be automatically
> >> started.
> > But what is the point of this? The /etc/crontab always exists and there
> > always are some files in /etc/cron.d.
> Actually it's true, but in the near future all standard cron jobs
> might be runned by systemd
> 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.
No matter how far down the wrong road you've gone, turn back.
More information about the devel