[systemd-devel] systemd-cron: retrigger generator after /var is mounted

Alexandre Detiste alexandre.detiste at gmail.com
Wed Oct 22 04:03:39 PDT 2014


> > -) how can I trigger a rerun of the generator 
> 
> generators are rerun if you issue "systemctl daemon-reload"

I already know, 

this is what our "trigger unit" does.
https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in
https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in

>> ... after /var is mounted.
this is the point I didn't get right.
Would linking cron-update.service in new folder 
(/usr)/lib/systemd/system/var.mount.wants/ 
do the trick ?

I currently start it from /etc/rc.local

> it's OK to cover /etc/cron.daily and friends natively with a generator
The issue with a generator is there must be some name mangling
to ensure that the units have an unique name and
unit name like 'cron-root-13.timer' in systemctl list-timers are not user friendly.
(we use now cron-$filename-$userid-$pkey.timer )

That is why cron.hourly|daily|weekly ... are provided as static units
that can be safely referenced in man pages;
this way systemd-cron can even work with an empty /etc/crontab .

> (and that's easy as the stuff is in
> /etc), but for the per-user stuff stored in /var it is a better idea
> to just leave traditional crond around, however, with one trick: only
> start it as soon as there is a file dropped into the cron subdir in
> /var. This way, users can use cron as they always did: as long as they
> did not install any user cronjobs everything works fine without crond
> started, and then when they install user cronjobs crond magically gets
> started in the background. The way how users install cronjobs is by
> invoking "crontab -e" anyway, and that tool needs to be installed
> anyway of the crond package, hence installing crond in a way that it
> is triggered via a crond.path unit should be OK too.
> 
> Hope that makes sense?
That makes sense, but I'm not responsible for packaging 'cron' in Debian;
that must also work for sysvinit. I doubt someone will like this half&half solution.

The crontab shipped with systemd-cron is written in python and can't be setgid like the real crontab;
so I asked if vixie-crontab could be shipped in an extra standalone package,
but I don't expect much more.


> > - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a shutdown,
> > it is not restarted on next reboot.
> 
> Hmm, could you file a bug about this issue on fdo bz? we should
> probably cover for this nicely.
https://bugs.freedesktop.org/show_bug.cgi?id=85321

Ok it's done, it would benefit native units too.



More information about the systemd-devel mailing list