[Dirvish] Dirvish jobs that run more than 24 hours

[Richard]

Keith Lofstrom wrote:
>
> <snip the stuff about all the scripts that CAN be run from individual 
> vaults>
>
> So my tendency is to leave dirvish alone, and do the complex and
> situation-specific stuff with relatively simple pre- and post- scripts. 
> I should post the scripts I use to the wiki.  Real Soon Now.
>   

OK. I understand that you are driving the train.  I understand that you 
are wanting to keep things simple.  The one 'issue' I have is when I 
sense you throwing the situation of a dirvish process wrapping over 
itself -- where a dirvish process/vault takes longer to complete than 
the interval between scheduled process times -- as something 
situation-specific.  I submit that you have incorrectly valued the 
severity of this problem.  I will do my best not to make this point 
again, but I'll emphatically make it now.

<soapbox>
"THERE IS NOTHING *SITUATION SPECIFIC*  -!EVER!- THAT WOULD CALL FOR A 
DIRVISH PROCESS TO WRAP UPON ITSELF AND TRY TO START /ANOTHER/ BACKUP 
BEFORE THE FIRST ONE EVEN HAD TIME TO FINISH.  DIRVISH PROCESS WRAPPING 
IS AN ERROR_CONDITION.   Including some mechanism in dirvish (be it code 
to ps |grep OR to use of something like PID files) to detect that a 
vault backup is currently running so that dirvish job wrapping can be 
avoided is the right and correct thing to do."

</steps down off the soapbox>

I wish I could program perl better.

While you say that two rsyncs shouldn't be running concurrently, I say 
that there are situations where it is VERY technically  feasible to do 
so -- and even desirable in some cases. As for my personal modification 
suggestion to your ps | grep line, it is merely a more precise version 
of yours that can be used for those who DO run rsync processes concurrently.

To Dick:   THANK YOU for that explanation!  It took me a long while and 
the help of others to understand it but it is wonderfully brilliant and 
simple!    To restate your point that I kept missing -->  by doing a 
seemingly meaningless escape of a normal letter on the grep line, we 
rely on the fact that grep will strip the backslash when it searchs the 
results of 'ps' thus eliminating the ability to find the actual process 
of the grep itself because the process containing the grep command will 
still contain the backslash!    BRILLIANT and so simple!

-- 
Richard