Le dimanche 27 janvier 2013 à 09:49 -0500, Sam Varshavchik a écrit : > Jaroslav Reznik writes: > > > Announcing various systemd features in one announcement, see bellow: > > > > = Features/SystemdCalendarTimers = > > https://fedoraproject.org/wiki/Features/SystemdCalendarTimers > > > > Feature owner(s): Lennart Poettering <lennart at poettering dot net> > > > > systemd has supported timer units for activating services based on time > > since > > its inception. However, it only could schedule services based on monotonic > > time events (i.e. "every 5 minutes"). With this feature in place systemd > > also > > supports calendar time events (i.e. "every monday morning 6:00 am", or "at > > midnight on every 1st, 2nd, 3rd of each month if that's saturday or > > sunday"). > > So, systemd wants to reinvent cron?
That's not exactly the same. Since a timer can be activated by a unit, or triggered by a inactive unit, you could for example run a job only if a unit is running. You can also directly express stuff that cron do not do such as running X secondes after boot, even if this could be done in cron too ( like @reboot, sleep 40 && stuff ). I guess also that since systemd support selinux ( https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), this permit to have a finer grained system for deciding who can or cannot disable a timer unit, with a selinux policy. On the other hand, cron just permit to edit the whole file, even if I guess you can work around this limitation with a clever system using /etc/cron.d/. > Based on systemd's prior track record of various parts breaking randomly > (namely the PrivateTmp fiasco), not really looking forward to this. You mean that PrivateTmp was not private at random, or that PrivateTmp activation broke software who relied on /tmp to be shared ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
