On Sun, Nov 5, 2017 at 8:10 AM, Ian Zimmerman <i...@very.loosely.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
