[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [gulus-miroir] Re: occasional error on ftp.cz.debian.org



Josip Rodin un jour écrivit:
On Sun, Nov 05, 2006 at 07:27:20PM -0500, Simon Valiquette wrote:

      $FROM $TO > $LOGFILE.2nd 2>&1
cat $LOGFILE.2nd >> $LOGFILE
rm $LOGFILE.2nd

 Replace the last line for:

         $FROM $TO >> $LOGFILE 2>&1

That will make the next 2 lines useless and avoid losing logfile.2nd if the script is terminated before the end or if the script is run a second
time in parallel (the command 'lockfile' in the script will not prevent it
in some special circumstences).


I don't see how termination before the end would lose anything,

If for some reason I decide to kill the script directly before killing the rsync process (It happened to me), and simply restart the script, $LOGFILE.2nd will be overwritten. You will get the same result after a sudent reboot or crash and under some other exceptional circumstances. It can also happens if you modify the script while it is used and it terminate without executing your commands.

I don't want to argue about it much. and didn't gave details because it makes change only under exceptional situations.

I just see that my proposition is a bit superior. You use a temporary copy that you will destroy after copying it to $LOGFILE. I do the same without using any temporary copy and with simpler code. That is more than enough to prefer this version.

Anyway, It is exactly what my scripts use since long ago, and I won't change it unless someone convince me that your version is better.

but yes,
running parallel scripts would cause horrible results. Yet, they aren't
limited to this snippet - the first rsync also does > $LOGFILE so you could
lose that too.

  Right.  That is why my script use >> for any output to the log file.
I should have pointed that.

Also, using >> just means that you would scramble $LOGFILE
if you kept appending to it in the middle of another rsync run.

I prefer that than losing the log. I already found useful error messages inside of such scrambled log files, which is better than not having the error message at all. Anyway, just the fact that my version is shorter and a little simpler is enough reason to prefer it.

  Good night,

Simon Valiquette



Reply to: