> > -) 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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
