[ProgClub programming] top: st : time stolen from this vm by the hypervisor

Roland Turner 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

    ...

    persistentDataDir=/var/lib/something
    alarm() {
      touch $persistentDataDir/alarm
    }
    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

    ...

    ephemeralDataDir=/var/run/something
    unlock() {
      rmdir $ephemeralDataDir/lock
    }
    trap unlock EXIT
    mkdir $ephemeralDataDir/lock

> 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).


- Raz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.progclub.org/pipermail/programming/attachments/20190605/935804d1/attachment.html>


More information about the programming mailing list