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

[Lennart Poettering]

On Wed, 22.10.14 09:56, Alexandre Detiste (alexandre.detiste at gmail.com) wrote:

> Hi,
> 
> I have been maitaining systemd-crontab-generator for some months,
> this is a generator developped outside of systemd that translates
> the crontabs in timer  & service units.
> 
> I have two unresolved bugs in our tracker that I don't know how to 
> tackle in the most "systemd-way".
> 
> Maybe you know better.
> 
> Here they are:
> 
> https://github.com/systemd-cron/systemd-cron/issues/26
> -) how can I trigger a rerun of the generator after /var is mounted.

generators are rerun if you issue "systemctl daemon-reload"

> There is already a trigger on PathChanged=/var/spool/cron/crontabs,
> but this doens't work, because cron.target is started after /var is mounted.
> 
> I already noticed the presence of /run/systemd/generator/var.mount;
> but I don't know how to glue it together.
> 
> Current trigger units:
> https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in
> https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in

So, I thought myself a couple of times about adding a cron generator
upstream, but always came to the conclusion that having to load the
configuration twice during boot-up would be suboptimal. The scheme I'd
hence propose is a different one: it's OK to cover /etc/cron.daily and
friends natively with a generator (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?

> https://github.com/systemd-cron/systemd-cron/issues/12
> 
> - ) 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.

Lennart

-- 
Lennart Poettering, Red Hat