Crash on LVM Snapshot cleanup #1071
Labels
No labels
blocked
breaking
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No milestone
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
borgmatic-collective/borgmatic#1071
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
I am trying to use the lvm snapshot function. Borgmatic creates the snapshot correctly, but fails to dismount it and crashes. The snapshot remains mounted.
Unmounting the snapshot with the command from the verbose log afterwards works without problems.
Steps to reproduce
No response
Actual behavior
/etc/borgmatic/config.yaml: Calling pushover hook function initialize_monitor
/etc/borgmatic/config.yaml: Calling pushover hook function ping_monitor
/etc/borgmatic/config.yaml: BORG_RELOCATED_REPO_ACCESS_IS_OK=*** BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=*** BORG_EXIT_CODES=*** borg --version --debug --show-rc
/etc/borgmatic/config.yaml: Borg 1.2.4
/mnt/backup/test.borg: Running actions for repository
/mnt/backup/test.borg: Creating archive
/mnt/backup/test.borg: Using runtime directory /tmp/borgmatic-c051i6km/borgmatic
/mnt/backup/test.borg: Calling bootstrap hook function remove_data_source_dumps
/mnt/backup/test.borg: Looking for bootstrap manifest files to remove in /tmp/borgmatic-/borgmatic/bootstrap
/mnt/backup/test.borg: Calling btrfs hook function remove_data_source_dumps
/mnt/backup/test.borg: Calling lvm hook function remove_data_source_dumps
/mnt/backup/test.borg: lsblk --output name,path,mountpoint,type --json --list
/mnt/backup/test.borg: Looking for snapshots to remove in /tmp/borgmatic-/borgmatic/lvm_snapshots/*
/mnt/backup/test.borg: Unmounting LVM snapshot at /tmp/borgmatic-q070lklo/borgmatic/lvm_snapshots/39c1d0350dfbcc9cbb0b/data
/mnt/backup/test.borg: umount /tmp/borgmatic-q070lklo/borgmatic/lvm_snapshots/39c1d0350dfbcc9cbb0b/data
/mnt/backup/test.borg: Error running actions for repository
/mnt/backup/test.borg: [Errno 2] No such file or directory: '/tmp/borgmatic-q070lklo/borgmatic/lvm_snapshots/39c1d0350dfbcc9cbb0b'
/etc/borgmatic/config.yaml: Calling pushover hook function ping_monitor
/etc/borgmatic/config.yaml: Calling pushover hook function ping_monitor
/etc/borgmatic/config.yaml: Calling pushover hook function destroy_monitor
/etc/borgmatic/config.yaml: An error occurred
summary:
/etc/borgmatic/config.yaml: Loading configuration file
An error occurred
Error running actions for repository
[Errno 2] No such file or directory: '/tmp/borgmatic-q070lklo/borgmatic/lvm_snapshots/39c1d0350dfbcc9cbb0b'
Need some help? https://torsion.org/borgmatic/#issues
Expected behavior
The snapshot should be unmounted and delted.
Other notes / implementation ideas
Config:
borgmatic version
2.0.2
borgmatic installation method
pipx
Borg version
borg 1.2.4
Python version
Python 3.11.2
Database version (if applicable)
No response
Operating system and version
Debian GNU/Linux 12 (bookworm) / RaspberryPi OS
Crash on LVM Snapshot cleanedto Crash on LVM Snapshot cleanupThanks for taking the time to file this. Is this log from a run where borgmatic both creates the snapshot and fails to unmount it? Or is it from a separate run afterwards where it only fails to unmount it, e.g. attempting to clean up from the previous run? Because it looks like the latter to me; I don't see anything about the snapshot being created. Do you happen to have logs from a run where the snapshot is created as well?
After borgmatic fails, can you recursively list the contents of
/tmp/borgmatic-q070lklo/borgmatic lvm_snapshots/39c1d0350dfbcc9cbb0b(or similar) and paste them here? (ls -Rortreewould work for this.)If you run
mount | grep lvm_snapshotsafter a failure, what shows up in that output?So you're saying that, for instance, borgmatic fails at
umount /tmp/borgmatic-q070lklo/borgmatic/lvm_snapshots/39c1d0350dfbcc9cbb0b/databut if you run that same command manually afterwards, it works?Thank you for looking into this!
Sorry, something seems a miss with the log I posted above. This issue does indeed occur when borgmatic creates the snapshot and then fails to unmount it during the same run. I have attached a new logfile where this is now properly shown (observe lines 28–35 and 70-76).
It appears that the already "/tmp/borgmatic-wtirlje8" does not exist.
mount | grep lvm_snapshotsreturns no output. However, runninglvsorlvdisplaydoes show the snapshot still exists. Output oflvs:This time the snapshot is no longer mounted, but I'm pretty sure that it remained mounted during some previous tests. Therefore running the umount command manually now produces an error (unlike I said above). I seem unable to reproduce the scenario where the snapshot remains mounted – but it does not get deleted and the crash persists.
This is really odd! Right before the unmount attempt, there's a check in the code to ensure the snapshot mount path exists (is a directory). If it doesn't, the unmount isn't even attempted. It's conceivable that something is removing the directory after the check and before the unmount, but I don't even know what that would be. You don't have another borgmatic process running at the same time, do you? Or anything else that could do automatic unmounts? borgmatic does remove the entire runtime directory (so
/tmp/borgmatic-wtirlje8in this case), but it only does that after the data source dumps are removed (and presumably unmounted).I honestly wouldn't know what else could unmount the directory. It would also seem odd to me that this would always happen at the same time during the borgmatic run. If something else were trying to unmount the snapshot, wouldn't borgmatic crash sooner while trying to read the files from the snapshot?
Another thing that speaks against some other process meddeling with the mount is that when I abort borgmatic with
ctrl-Cafter the snapshot was created but before it attempts to remove it, it remains mounted (as one would expect). If some other process were unmounting it, I would expect it to unmount it even if borgmatic is aborted.There is no other borgmatic process running. I have so far only tried to run it manually with
borgmatic createand set up no automations that would launch a second process.Perhaps some more info about my filesystem in case that helps:
As you can see, I have
sda1mounted to/mnt/backup. This is a USB stick on which I have the borg repository for testing purposes.mmcblk0is the SD-Card in the PI which has a small boot partition and a larger partition that is encrypted with LUKS. Below LUKS there are my two lvm volumesroot_filesystemanddata. I am trying to backup/data. I have separated my data to this lvm-volume to use the snapshoting feature.I am not currently dumping any databases and just want to backup /data as a whole. Eventually I would like to do what the user in #790 was trying: Stop containers before the snapshot and start them immediately after. I'm unceirtain if borgmatic 2.0 has made this possible or not. At least I don't really understand how I would configure that.
I might just try to reinstall the OS and see if I can reproduce the problem if we can't figure it out.
Thanks for the additional details. I agree that it doesn't seem likely that another process is meddling with the mount point here.. I'm just looking for any possible explanation here!
So my next theory is that the error isn't actually coming from the unmount, but rather the unmount is succeeding and then the
No such file or directoryerror is happening in some code after the unmount. Especially because the path in the error isn't exactly the same as the path being unmounted.Would you feel comfortable finding and changing the borgmatic source code on your machine to validate that theory? Since you installed via
pipx, I'm guessing that the code in question is located at~/.local/pipx/venvs/borgmatic/lib/python3.11/site-packages/borgmatic/hooks/data_source/lvm.pyor thereabouts. And the line in question is line number 4110. You could try changing this:... to this:
My thinking is that this change should suppress the error you're seeing, which might be just fine because the snapshot is still getting unmounted and subsequently deleted.
That feature (command hooks around
dump_data_sources) did not ultimately get released, because it turned out it did not meet that particular user's needs. But feel free to open a separate ticket and we can discuss it there.I'm pretty confident this change will fix this for you, so I went ahead and pushed it to main and I've just released it. This means you shouldn't have to change anything locally to try this out if you upgrade to borgmatic 2.0.3. But please still report back if it solves this for you. Thanks!
Thank you so much! This did indeed fix the issue and everything is working as expected now.
I would also like to take a moment and compliment the way you're handeling the reported issues here. It is unfortunately rare to find discussions in such a friendly and helpful tone – so thanks for this too.
Awesome, I'm glad to hear that did it! And thank you for the kind words.