Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

GUI freezes when opening Settings: Device.unmount() runs a global sync on the GTK main thread and waits for all filesystems in the system

Aperta
  • Qualcosa non va?
#572 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
57/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Ambito
backend, desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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:

  1. Bare sync flushes dirty data on every mounted filesystem in the system, not just the one being unmounted.
  2. 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!

Lingua principale
Vala
Stelle
4.3k
Fork
159
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di linuxmint/timeshift

Tutte le issue di linuxmint/timeshift

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.