Re: Proposed F19 Feature: systemd features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/27/2013 04:36 PM, Michael Scherer wrote:
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/.

I would say that work even before. If I should say according to number of bugs, not many users were using specific SElinux contexts for cronjob tasks.

No objection to this feature, it might be very powerful for some use-cases. I'm afraid of situation, when half of cronjobs will be converted and half stay as is. Poor admins.

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 ?


Marcela
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux