<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/28/2013 02:56 PM, Marcela
Mašláňová wrote:<br>
</div>
<blockquote cite="mid:51069191.3010904@redhat.com" type="cite">On
01/27/2013 04:36 PM, Michael Scherer wrote:
<br>
<blockquote type="cite" style="color: #000000;">Le dimanche 27
janvier 2013 à 09:49 -0500, Sam Varshavchik a écrit :
<br>
<blockquote type="cite" style="color: #000000;">Jaroslav Reznik
writes:
<br>
<br>
<blockquote type="cite" style="color: #000000;">Announcing
various systemd features in one announcement, see bellow:
<br>
<br>
= Features/SystemdCalendarTimers =
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://fedoraproject.org/wiki/Features/SystemdCalendarTimers">https://fedoraproject.org/wiki/Features/SystemdCalendarTimers</a>
<br>
<br>
Feature owner(s): Lennart Poettering <lennart at
poettering dot net>
<br>
<br>
systemd has supported timer units for activating services
based on time since
<br>
its inception. However, it only could schedule services
based on monotonic
<br>
time events (i.e. "every 5 minutes"). With this feature in
place systemd also
<br>
supports calendar time events (i.e. "every monday morning
6:00 am", or "at
<br>
midnight on every 1st, 2nd, 3rd of each month if that's
saturday or sunday").
<br>
</blockquote>
<br>
So, systemd wants to reinvent cron?
<br>
</blockquote>
<br>
That's not exactly the same.
<br>
<br>
Since a timer can be activated by a unit, or triggered by a
inactive
<br>
unit, you could for example run a job only if a unit is running.
You can
<br>
also directly express stuff that cron do not do such as running
X
<br>
secondes after boot, even if this could be done in cron too (
like
<br>
@reboot, sleep 40 && stuff ).
<br>
<br>
I guess also that since systemd support selinux
<br>
( <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl">https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl</a>
),
<br>
this permit to have a finer grained system for deciding who can
or
<br>
cannot disable a timer unit, with a selinux policy.
<br>
On the other hand, cron just permit to edit the whole file, even
if I
<br>
guess you can work around this limitation with a clever system
<br>
using <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>etc/cron.d<span
class="moz-txt-tag">/</span></i>.
<br>
<br>
</blockquote>
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.
<br>
<br>
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.
</blockquote>
<br>
It only makes sense to migrate the cron jobs that daemon/services
bring in with them ( ca 38 out of 99 ) and I cant see how this is
supposed to be "poor sysadmins"? It's simple if it's an
daemon/service related it's being handled by systemd timers if not
it's being handled by cron. The rest of those packages that bring in
cron script should be fixed to require cron ( which is not the case
now )<br>
<br>
JBG<br>
</body>
</html>