New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repoctl is backing-up files without any good-reason #58
Comments
This time |
So sorry! I'm looking into it. |
Luckily I logged the moment it backed up everything this second time:
|
Could you post the output of |
|
That looks like the output of the bug that already got fixed... hmm. I wonder if |
😅 this was with aur.archlinux.org/packages/repoctl |
Oh boy... |
I got it from the pacman's cache: |
Ah, you might consider using |
I may have missed updating it 😅 I'll have to wait for the recompilation cycle to get in letter R. |
My guess is that might be it. I might have messed up the PKGBUILD for the go module migration, which could result in local Go modules being used instead of the vendored ones... This was before I followed the updated Arch Go packaging guidelines for modules. |
And the error you describe here is one that got fixed in one of the dependencies of repoctl. So there might be that mismatch. Also, I downloaded the package that caused the trouble and followed your procedure locally and didn't have any trouble, so at least I can't reproduce it with 0.21-2 and 0.21-3. |
One notice, when EDIT: I've updated to |
Oh interesting, I should look into that. I think I'm starting to understand the backup behavior. Has to do with how repoctl reads all data first and then tries to act on it. |
Also, a partially-written archive would pose some problems, because repoctl only reads as much of a package as it needs to; currently I'm relying on repo-add to handle the case of an incomplete file. |
Yeah, |
So one thing I could definitely do is have |
Alright then that change is now on |
And you're saying that adding this package to database actually caused all the packages in the repository to be backed up? |
Moved to it 👍 By the end of the recompilation cycles, I'll let you know if something goes wrong.
Yeah, The full logs have a bunch of "Backing up..." after this |
The full log: |
So bizarre that I can't get that backup-behavior reproduced at all... :-( |
I was using 0.21 since #57 was closed, and only now it happened (and then again, but after building 800 packages in a small-time period). |
Do you run repoctl update while building other packages? |
I do, the server has 40 vCPUs, I don't like to leave any of these idle 😊, so it's a chaos of |
Ok... that explains a lot. 😄 This would have been very useful to know earlier. So far I haven't considered the ramifications of parallel updates and adds. This is a tricky one. |
Actually I'd also be interested in hearing any pain-points you might have in building that many packages. For example: I've always found the situation difficult where you need to build newer dependencies that then need to be installable for the next |
I think it would be better to create a new issue specifically for the use-case "Support parallel execution of repoctl". |
😅 someway somehow I managed that, my first infra has a "batch" command, and I execute it like this: (And the second one has a |
Sometimes I still get:
Sometimes is uglier:
But these packages are still being added to the repo... As the catastrophic event seems to have ceased, I'm closing this issue. |
Hey @PedroHLC, the errors you are seeing there are to be expected when repoctl reads
If repoctl encounters these files, it should just ignore them. Further final thoughts from me:
Quick question: Do you run |
I observed it today, and repoctl is not running in parallel. My lock wrapper is working and probably has been the way the entire past year. I just don't avoid partially written files. But I'm considering using the same lock file for the copying operations... |
Sadly it happened once more, with |
Good to know that it can also happen by itself! Debugging data-race issues are really really hard, because a lot of behavior is just undefined, which can mean basically anything. But if it happens without any other instance running in parallel, then I might just have a chance to observe it myself. If you ever manage to reproduce it reliably, that is of course the absolute best, but from the sound of it that doesn't happen. Do you know if anything else was running at the same time, e.g. Pacman? I opted to not use libalm, the Pacman libraries, because it was always annoying to have to recompile a tool like cower every time I updated pacman. But that means that I had to come up with the database reading myself, which isn't as battle-tested as that from Pacman. |
Sadly it took me 40hrs to notice the packages were gone 😅 |
I had one entry showing as This package wasn't even appearing in my dump with I've added it with
It shouldn't be running, for except inside some containers... |
Over the years I've also noticed (and had reports) of local repository database suddenly becoming empty. Never found out the cause either. In my case, |
Hi @cassava,
I just lot the entire repository twice today, the files were moved to the backup directory.
Tasks used includes (only)
repoctl update
andrepoctl add <some kernels>
.I'm using the 0.21 release.
The text was updated successfully, but these errors were encountered: