On Wed, 22.10.14 09:56, Alexandre Detiste (alexandre.deti...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel