On Sat, Mar 2, 2019 at 8:25 PM Michael Orlitzky <[email protected]> wrote: > > Using run-parts in /etc/crontab also has its problems, but I don't have > a solution handy for that one. Using run-parts runs those daily, weekly, > etc. jobs as root, which may not be what you want if you're operating on > user-controlled data (e.g. bug 662438). The best way to solve this would > be to let packages install their own crontab entries into a directory > like /etc/cron.d, but that location isn't standard. >
So, the problem with cron.d is that you're now using crontab syntax, and for compatibility you have to use the lowest common denominator which is vixie. That means your jobs are STILL running as root, so the only problem you had with run-parts isn't solved. In addition you lose the ability to cover the desktop use case of non-24x7 systems running infrequent tasks. If you used vixie cron syntax for a monthly job it might never run at all on a typical desktop, as it would have one opportunity to run in a month, at one time of day. The crontab syntax also forces each package maintainer to pick the time of day their jobs run at, vs just letting the sysadmin choose the time the entire set of scripts is run. I'm sure there are alternatives like adding a compatibility layer (which is basically what run-crons already is), or some kind of helper where an ebuild can give it a set of parameters and it installs the task for whatever cron implementation eselect points it at. I'm just not sure that they are worth the complexity or provide much more value than the existing solutions. This is also somewhat orthogonal to run-crons, where you still are left with the choice around whether to use it with vixie or other implementations that don't support more desktop-oriented use cases. This is of course why that bug has been fairly intractable. -- Rich
