[ProgClub programming] top: st : time stolen from this vm by the hypervisor
roland at rolandturner.com
Wed Jun 5 12:23:02 AEST 2019
On 5/6/19 5:43 am, John Elliot V | ProgClub wrote:
> "reasons" for not using cron:
> 1. I want to watch what my process is doing, in colour, in real time
syslog and multitail/grc
> 2. I want to start/stop/restart my process at any point in time
That seems an incompatible requirement with automated maintenance,
particularly backups. Inevitably your attention will be drawn to
something else and automated maintenance that is set up to fail when
you're not watching will fail, placing you in the dilemma of either
stopping the more useful activity to fix it, or leaving it broken. This
would appear a comparable position to that an earlier comment that you
made along the lines of never expecting your backup scripts to be
reliable. For a competent programmer, this is a surprising, even
shocking position. If you don't believe that you can reliably automate
(say: 1 failure/decade) such rudimentary processes, what hope do you
have with more complicated code?
> 3. I want to make sure my process doesn't automatically restart if it
> exits due to error
Assuming that you're not ready to embrace systemd (which, despite the
absurd documentation, is actually pretty simple for common cases):
#! /bin/bash -e
trap alarm ERR
[ -f $persistentDataDir/alarm ] && exit 1
> 4. I want to make sure only one copy of my process runs at a time
Under the same assumption:
#! /bin/bash -e
trap unlock EXIT
> The intersection of those requirements does not lead to cron.
Not by themselves, but incorporating your later comments about not
trusting software "which haven't been widely used for long periods of
time in diverse environments" would appear to point towards using cron
or systemd in preference to writing your own timing logic, even if you
happen not to stumble onto octal problems.
> (I would need my shell script + systemd
> configuration + a log file, which is more complicated than having just
> my script).
That is not true. Your script would be simplified by virtue of not
having to replicate existing, very thoroughly tested capabilities. The
fact that you'd need a shell script and a configuration file instead of
just a more complex shell script does not make it more complex. In
almost all cases, it makes it less complex.
>> This is turning out to be dreadfully useful: https://xkcd.com/1205/
> You've mentioned it three times and each time your intent went right
> over my head. What are you trying to say? That I'm wasting my time by
> writing a shell script to do my backups?
You are perhaps allowing the perfect be the enemy of the good: that you
can't solve all of the problems (eliminate all bugs) by using existing,
well-tested infrastructure code does not mean that it's reasonable to
abandon existing, well-tested infrastructure; it means that it's
reasonable to pursue the path with fewer bugs and less complexity (even
if there are a larger number of files in total).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the programming