The sound distributed version control system

#482 bug: open file limit consistency issue

Closed on December 7, 2021
ammkrn on July 18, 2021

The issue with the ulimit open files thing was discussed briefly on zulip. Apparently this can cause consistency issues in the following manner:

  1. User tries to pull changes they don’t have yet
  2. Pijul aborts for too many open files, but leaves the files it touched “half-applied”
  3. User raises ulimit and pulls again, this time the pull completes

There are now overlapping conflict markers/revisions, from both the failed pull and the completed pull. The consistency issue is thatpijul reset is not able to “fix” the repo; you’re stuck with some artifacts from the first partial apply. This seems to happen whether the changes are in the local remote cache or not, but it doesn’t happen if the changes being applied are changes that were unrecorded and are being reapplied. It might be the case that unrecord --reset <hashes> applied to the new patches, then reset would work.

pmeunier added tag Beta on August 4, 2021
pmeunier removed tag Beta on August 4, 2021
pmeunier on August 4, 2021

When pulling, Pijul records a “pending” patch, pulls, outputs the result and unrecords the pending patch.

I’m not sure why this error happens, since nothing should be committed in the case of a crash. The second call to pull will produce a garbage pending patch, but that one will be unrecorded at the end of the pull.

I’m leaving this open, but without a way to reproduce there isn’t much we can do. If this happens to anyone again, I’d be interested in a tarball of the repository (send it by email to pe@pijul.org), as well as their value for ulimit on the number of open files.

pmeunier on December 7, 2021

I’m closing this since I can’t reproduce. I guess it hasn’t happened again since my last comment, it could be fixed. Let’s see if someone else experiences this in the future.

pmeunier closed this discussion on December 7, 2021