[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