On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote:
2010/11/25 Tomas Mraz <tmraz(a)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
>> Basically, in your .path unit you'd write something like this:
>> 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
> 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.