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

Tomas Mraz tmraz at redhat.com
Thu Nov 25 07:39:45 UTC 2010


On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: 
> On Wed, 24.11.10 15:22, Paul Wouters (paul at xelerance.com) wrote:
> 
> > 
> > On Wed, 24 Nov 2010, Lennart Poettering wrote:
> > 
> > > BTW, regarding at and cron: what I was thinking of but never check
> > > ehwther it is feasible is to make cron/at autostart a soon as some job
> > > is scheduled. I.e. use .path trigger to check whether /etc/crontab and
> > > user jobs exist, and start cron only then. Similarly for at. That way we
> > > could support cron and at just fine, and wouldn't even have to run it by
> > > default. I haven't looked into this in detail however, to see if the
> > > file triggers systemd offers in .path units are already sufficient to
> > > make this work.
> > 
> > What if no jobs are there and a non-root user adds a crontab later on? Who
> > will start cron (as root) ?
> 
> 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.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



More information about the devel mailing list