Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Rich Freeman]

On Sun, Nov 5, 2017 at 8:10 AM, Ian Zimmerman <itz@××××××××××××.org> wrote:
> On 2017-11-05 07:11, Rich Freeman wrote:
>
>> But, I agree that it makes far more sense to just have desktop users
>> use an appropriate cron implementation designed to handle the machine
>> being off most of the time vs trying to use shell scripting to make
>> vixie cron into such an implementation.
>>
>> FWIW this is probably the reasoning behind including cron-like
>> functionality in systemd, and having it support optionally running
>> jobs if the system was down during a calendar-based event.  It was
>> considered bare-bones functionality that any desktop or generic server
>> would need.
>
> If Kai is right that fcron handles it, the reason is probably systemd
> people thought that had to match the functionality to be considered a
> full replacement.  Especially since fcron is the normal system cron on
> Fedora/RH, right?

Honestly, I think it is more because it is almost impossible to cover
both desktops and servers without these features, so there is little
point in adding timers if you don't support both.  The reason they're
there at all is because it falls into "core functionality" which is a
goal of systemd - it is a bit like busybox in that regard (and, indeed
busybox also implements a crond).

However, while systemd aims to go further than busybox it doesn't
actually aim to replace all the other tools that it overlaps with.
For example, resolved isn't a full substitute for bind, and timesyncd
isn't a full substitute for ntp (the latter of which is relatively
popular on random systems and not just dedicated servers).  In general
they try to focus on the client-side stuff only, with a moderate but
not minimal scope.

>
>> I personally use systemd-cron which basically is a wrapper+generator
>> around /etc/crontab and the various /etc/cron.*/ scripts.
>
> If your dislike for having this in cron itself comes down to shell
> script vs. C code, and it appears so from the above, I'm not at all sure
> I agree.  This to me seems one of the few tasks where shell script is in
> fact a good fit: mainly looking at files, timestamps, and running other
> programs.

So, two things here:

First, I'm honestly not sure I buy that shell scripts are the best
tool here.  Yes, they can look at files and timestamps, but I tend to
be of the school that shell scripts are poor environments to write
actual software in.  At best they work reasonably well for glue.  I'm
not advocating for C, but if I were implementing a cron I wouldn't be
doing it in bash.

Second, my actual objection is more to sticking wrappers around an
upstream program just to extend its capabilities, when other software
is maintained upstream that already does what you're re-inventing.
When you already have 47 different cron implementations out there, I'm
not sure it adds a lot to have a distro-specific solution.  The distro
should certainly be providing stuff like /etc/cron.*/ and the scripts
inside when upstream isn't providing them.  By all means include a
stock wrapper /etc/crontab that runs that stuff at set times for those
running 24x7 with vixie cron.  If run-scripts was implemented in
python instead of shell this objection wouldn't go away.

Sure, back in the early days of Gentoo maybe it made a little more
sense to have our own tools just like everybody else did, and I'm not
sure I'd advocate to go removing them either.  However, I can
certainly sympathize with WONTFIX when people want to continue to add
features to them.  They're just a minimal starting point that is
implementation-agnostic - use the right tool if your requirements
exceed these.


-- 
Rich