Re: soliciting opinions about potential new cron/at features.
Craig Sanders <cas@taz.net.au> writes:
All of the following is not to say that I wouldn't be happier with an
solution that didn't involve modifying cron or at, but I haven't been
able to think of a good one yet (see reasons below).
Feel free to make suggestions. However, I tend to feel that GnuCash
isn't the only app that would benefit from this feature, so it would
be a waste to just add this functionality to GnuCash if a similar
amount of work to cron could provide a general solution everywhere.
> what i can't understand is why end-user stuff like this needs to be
> handled by the system administrator.
It doesn't, but I think it does need to be handled by the system
(i.e. cron). The administrator wouldn't have to know anything about
the stuff I'm talking about, any more than they have to know about the
user's current existing single crontab.
[FWIW, I *am* opposed to the sugeestion that there should be an
~/.cron.d. This stuff shouldn't go in the user's directory for all
the same reasons that the current user crontab shouldn't go in there
(unreliable or slow home dirs, dangerous actions by the user, etc.)]
> if an end-user needs to do something like this, why can't they
> schedule their own job (with cron or at - even at can be made to do
> regular jobs if the last command of the script inserts itself into
> the at queue again)?
Because (in the case of GnuCash for example), we don't want the
average user in the loop (we're still going to allow advanced users
all the scriptability they can handle, but even they may prefer the
easier mechanism for straightforward tasks).
For example, if the user uses GnuCash's GUI to say that they want
GnuCash to "put $120 dollars into my savings account every 3rd
Wednesday", we want to make sure that this happens with extremely high
reliability, and with as few points of failure as possible.
Having Gnucash edit the user's crontab to add this "event" isn't an
option (for the previously mentioned reasons). Having the user add a
"run a gnucash helper every 5 minutes and see if anything needs to be
done" command to their crontab is IMO both inelegant and inefficient,
though workable with some careful lockfile handling. If 20 users do
this, then you've got 20 tasks going off every 5 minutes for
absolutely no reason. On the other hand, forcing the user to add a
line to their crontab for every single financial event that they want
to have run leaves users that actually want a GUI interface in the
dark, sets you up for even more potential race conditions, and limits
the flexibility of the scheduling.
(For example, cron's scheduling isn't nearly as sophisticated as
emacs's calendar mode, and with guile built in, GnuCash might
eventually want to do more complex scheduling than cron can handle.
In such a situation, cron is still fine as the instigator since
GnuCash can always figure out the time for the next event in line and
give that to crontab --section GnuCash).
Having GnuCash schedule an at task to handle the next job with the
assumption that that task will schedule another task for the next
deadline isn't really workable since if the user adds a new event that
should happen *before* one already scheduled, there's no easy/portable
way to remove the old one reliably -- which one is it? Further, using
the user's general at queue makes it all too easy for them to
accidentally delete the GnuCash event(s) (especially since at doesn't
allow you to label events in the at queue with a meaningful
string...you just see numbers and times).
The modification to cron I proposed (or the at modification, we
probably don't have to have both) would avoid all these problems while
using a minor variation on an existing and tested mechanism (Debian's
cron.d).
> IMO this is analagous to using a sledgehammer to kill a mosquito
> which has landed on a glass ornament....you'll probably get the
> mosquito but you'll almost certainly break the ornament too.
I really didn't see it as quite that dramatic. You just have multiple
user crontabs. The user never sees anything but the one they see now
unless they specifically ask to (with --section). Each of the
non-user crontabs is checked just like the users (so you're not likely
to end up with broken ones installed, and it's run via the cron.d code
(which works).
(Note that I *think*, but I'm not positive yet, that either enhancing
cron as I have suggested *or* fixing at to provide optional unique
job id's would be sufficient. We don't have to have both. Although
I still prefer the crontab --section approach because it makes it
very hard for the user to accidentally do the wrong thing with atrm
and end up preventing their automatic transactions from occurring
(possibly a catastrophe depending on the user). A slightly more
sophisticated at fix would also avoid this problem.)
That was a little more long-winded than I intended to be.
Apologies.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: