GUI freezes when opening Settings: Device.unmount() runs a global sync on the GTK main thread and waits for all filesystems in the system
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 57/100
Research direction
Start in src/Utility/Device.vala at the “sync before unmount” block in Device.unmount(), then trace the Settings and Wizard device probe path through check_btrfs_volume(). Confirm how unmounting flushes the target filesystem and whether removing the global sync preserves the expected behavior. Done when opening Settings or Wizard no longer blocks the GTK UI on unrelated filesystem writeback.
Written by the indexing model from the issue text.
Description
Hello! We tracked down a GUI freeze in timeshift-gtk to a specific line of code and would like to share the analysis.
Describe the bug
Clicking "Settings" (or "Wizard") in the main window freezes the whole GTK window until it is killed. The freeze is not limited to the Settings dialog — no UI events are processed at all.
Root cause
Device.unmount() (src/Utility/Device.vala, the //sync before unmount block) runs a global sync before unmounting:
//sync before unmount
cmd = "sync";
Process.spawn_command_line_sync(cmd, out std_out, out std_err, out ret_val);
Two problems here:
- Bare sync flushes dirty data on every mounted filesystem in the system, not just the one being unmounted.
- spawn_command_line_sync is called on the GTK main thread, so the whole UI blocks until sync finishes.
Opening the Settings window probes the BTRFS device (check_btrfs_volume() mounts it temporarily with subvolid=0, then unmounts it), which reaches this code path. If any disk in the system has a large dirty writeback backlog, sync blocks for as long as that backlog takes to drain — the GUI hangs meanwhile, even though the slow disk has nothing to do with Timeshift.
This is similar to #232 (closed as stale), where the debug log ends at Unmounting from: '/run/timeshift/.../btrfs' — the same code path — but the underlying mechanism was never identified there.
Evidence (timeshift 26.09.0-1, Arch Linux, kernel 7.2.9-arch1-1)
During the freeze, a child sync process of timeshift-gtk sits in uninterruptible sleep (D state) for many minutes:
$ ps -eo pid,ppid,stat,etime,cmd | grep sync
838004 1 D 24:01 sync
839348 838637 D 10:47 sync # child of timeshift-gtk
Kernel hung-task reports confirm it is waiting for writeback:
INFO: The task sync:838004 has been waiting for writeback completion for more than 1305 seconds.
The cause of the slowness is an unrelated external USB SMR drive with a large writeback backlog (~17 GiB of dirty pages, ~6 MB/s sustained write):
Dirty: 17508360 kB
Writeback: 8192 kB
/proc/diskstats for that drive shows it is 100% busy writing at ~6 MB/s, so sync waits ~45 minutes. The GUI is unresponsive for the entire duration.
Expected behavior
The UI should not freeze because of unrelated disks in the system.
Suggested fix
Remove the global sync call from Device.unmount(). The umount syscall already flushes the filesystem being unmounted — a system-wide sync is redundant even for the target device, and it is actively harmful in a GUI process. If some extra safety is desired, syncfs() on the target filesystem's fd would be scoped correctly, but even that is unnecessary here since umount handles it.
Alternatively, at minimum, do not run it synchronously on the GTK main thread.
Thank you for your work on Timeshift!
- Dominant language
- Vala
- Stars
- 4.3k
- Forks
- 159
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from linuxmint/timeshift
-
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
timeshift --create hangs indefinitely at exit in infinite read() = 0 loop on aarch64 (Fedora 44 / Kernel 7.2.x)Possibly taken @ygerlach claimed this 2 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 28/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
All issues in linuxmint/timeshift
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
maxrave-dev/SimpMusic#2649 ·
Maintainers usually reply within 2 days
-
product/backlog
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
TencentBlueKing/bk-nodemgr#3645 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
Objects.List treats versions=false (and similar flags) as truePossibly taken @andaaron claimed this today. Openpriority: p2 type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
googleapis/storage-testbench#829 ·
Maintainers usually reply within 2 days
-
[Bug]: memory provider treats 1:1 DMs as shared surfaces, so DM turns never receive reviewed recordsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
rlaope/oh-my-hermes#2088 ·
Maintainers usually reply within 1 day