Repeated unmount attempts in cleanup_unmount_devices()
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- Nửa ngày
- Mức phù hợp với người mới
- 63/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- backend
Hướng nghiên cứu
Start in src/Core/Main.vala and read cleanup_unmount_devices(), focusing on how it iterates over filesystems and mount points after unmounting a path. Reproduce with timeshift --check --scripted and inspect the cleanup behavior; done means each temporary mount point is processed once and the repeated unmount errors no longer appear. The proposed change is untested, so compile and verify it before relying on it.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Hi,
Using Mageia 10 + Timeshift 25.12.2-1, I've got some (non-blocking) errors in the timeshift logs (see below).
ChatGPT helped me to understand the issue and proposed a change in the code that I didn't test as it would have required me to install about 600 dependencies on my server.
Environment
- Timeshift: 25.12.2
- Distribution: Mageia 10 (timeshift-25.12.2-1.mga10)
- Snapshot mode: RSYNC
- Snapshot destination: ext4 filesystem on an LVM logical volume (
/dev/dm-2)
Bug description
When running timeshift --check --scripted, Timeshift repeatedly attempts to unmount the same temporary mount point during cleanup_unmount_devices().
The first unmount succeeds, but Timeshift continues to attempt to unmount the same path, producing five additional errors.
This happens both when a snapshot is created and when Timeshift performs a scheduled check without creating a snapshot.
Example log:
Found stale mount for device '/dev/dm-2' at path '/run/timeshift/2769423/backup'
Unmounted successfully
Found stale mount for device '/dev/dm-2' at path '/run/timeshift/2769423/backup'
E: Failed to unmount
Ret=8192
E: Failed to delete /run/timeshift/2769423/backup
The error messages are repeated five times.
Despite these errors, snapshots are created successfully, and no temporary mounts remain after Timeshift exits.
Investigation with strace
I traced Timeshift using:
strace -f -tt -s 256 \
-e trace=mount,umount2,execve,rmdir,unlinkat \
-o /tmp/timeshift-strace.log \
timeshift --check --scripted
The relevant system calls are:
umount2("/run/timeshift/2769423/backup", 0) = 0
rmdir("/run/timeshift/2769423/backup") = 0
umount2("/run/timeshift/2769423/backup", 0) = -1 ENOENT
umount2("/run/timeshift/2769423/backup", 0) = -1 ENOENT
umount2("/run/timeshift/2769423/backup", 0) = -1 ENOENT
umount2("/run/timeshift/2769423/backup", 0) = -1 ENOENT
umount2("/run/timeshift/2769423/backup", 0) = -1 ENOENT
The initial unmount succeeds, and the temporary directory is removed successfully. The following attempts fail because the directory no longer exists.
Suspected root cause
The problem appears to be in src/Core/Main.vala, in cleanup_unmount_devices().
The function loops through all filesystems returned by Device.get_filesystems() and their mount points:
foreach (var dev in Device.get_filesystems()) {
foreach (var mnt in dev.mount_points) {
if (mnt.mount_point == mdir2) {
// Unmount and remove directory
}
}
}
On my system, the same mount path appears to be encountered multiple times. The function continues processing it even after it has been successfully unmounted and removed.
Proposed patch (not tested)
The following minimal change stops processing the mount point after the first matching entry.
--- a/src/Core/Main.vala
+++ b/src/Core/Main.vala
@@
- foreach (var dev in Device.get_filesystems()){
+ bool mount_processed = false;
+
+ foreach (var dev in Device.get_filesystems()){
foreach (var mnt in dev.mount_points){
@@
if(!dir_empty_delete(mdir2)) {
log_debug("E: Failed to delete %s".printf(mdir2));
}
+
+ mount_processed = true;
+ break;
}
}
+
+ if (mount_processed) {
+ break;
+ }
}
This preserves the existing unmount and error-handling behavior while avoiding repeated attempts to process the same mount point.
Expected behavior
Timeshift should attempt to unmount each temporary mount point only once.
After a successful unmount, it should not report additional errors for the same path.
Actual behavior
Timeshift successfully unmounts and removes the temporary directory, then repeatedly attempts to unmount the same nonexistent directory.
Additional information
The proposed patch has not been compiled or tested. It is included as a possible fix for maintainers to review.
I would appreciate confirmation of the root cause and whether this approach is appropriate.
Regards.
Xuo.
- Ngôn ngữ chính
- Vala
- Star
- 4.3k
- Fork
- 159
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của linuxmint/timeshift
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 78/100
-
License parsing with GitHubĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 56/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 50/100
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Tất cả issue của linuxmint/timeshift
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
step.duration reflects only the last retry attempt (HelperStep.run() overwrites startTime)Có thể đã có người làm @mirao đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
codeceptjs/CodeceptJS#5774 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug mac アプリ: コード アプリ: チャット 優先: 中 要トリアージ
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
yksr-melt/Meltype#1346 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
aws/context-ontology-accelerator#336 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
b:minor bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
software-mansion/argent#1698 ·
Maintainer thường phản hồi trong vòng 1 ngày