Re: Multiple cvs/git mirror tasks?

[Jim Meyering <jim@meyering.net>]

Jason Merrill wrote:
> On 07/20/2012 12:19 PM, Jim Meyering wrote:
>> At first glance, you may think there are three invocations of the script,
>> but as recently discussed here, that's merely due to a subshelled
>> pipeline in the script: each element of the pipeline ends up looking
>> (in ps output) like another invocation of the parent script.  It really
>> was invoked only once.
>
> Right, but in the ps output I sent before, there were two gdb runs
> (each with 3 processes) running at the same time.
>
>> I'm leery about adding naive cross-project locks, because that could
>> let a busy project starve one that needs only a tiny update.
>>
>> Using lockfile(1) and a timeout might help.
>>
>> I could add a per-project locking mechanism to prevent e.g., two gdb
>> syncs from running in parallel when the first one takes more than the
>> 30m between cron invocations.  That could save some system resources,
>> but would not improve correctness or integrity.
>
> That makes sense to me.  The times when it would run long are likely
> to correspond with times when system resources are tightest, as with
> the time I noticed.

I've just adjusted the script (~meyering/bin/mirror-sw) to do that.
[I did have qualms about doing this locking business in sh,
and even implemented it first in Perl, mainly because using a
diagnostic to distinguish the EEXIST case from other mkdir failure
is so ugly.  Finally I opted for this in-script sh code rather than
a separate perl script.]

Now it starts like this:

  ...
  repo=$1

  # =============================================================
  # Require a lock per repository, in case a sync operation
  # takes longer than the interval between cron job invocations.
  # It doesn't affect correctness when two of these jobs run concurrently,
  # but it is definitely wasted work and can contribute to performance problems.

  lock_dir=$HOME/mirror-git-to-cvs/$repo.lock

  export LC_ALL=C # we require an English diagnostic from mkdir
  err=$(mkdir $lock_dir 2>&1)
  if test $? = 0; then
    echo $$ > $lock_dir/pid
  else
    case $err in
      *exists)
        test -d $lock_dir || die "$lock_dir is not a directory?!?"
        pid=$(cat $lock_dir/pid) || die "no $lock_dir/pid file?!?"
        # See if PID is still valid.
        kill -1 $pid 2>/dev/null \
          && die process $pid remains \
          || {
               # process $pid is dead; steal lock
               echo $$ > $lock_dir/pid
             }
        ;;
      *)
        # mkdir failed; print the diagnostic we recorded
        die "$err"
        ;;
    esac
  fi
  # =============================================================

and cleans up at the end with "rm -r $lock_dir"

FYI, since I've begun collecting sync-job duration data,
the vast majority of them have finished in under 10 minutes.
Here are the few (duration in seconds) that did not:

    1132
    803
    797
    704
    684
    671
    658
    657
    656
    646
    631
    609
    607
    602