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

timeshift --create hangs indefinitely at exit in infinite read() = 0 loop on aarch64 (Fedora 44 / Kernel 7.2.x)

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

@ygerlach ci sta già lavorando.

Dal 10/10/2026.

  • #571 di @ygerlach — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
28/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
linux, raspberry-pi
Ambito
operating-systems

Direzione di ricerca

The reported loop is in src/Core/AsyncTask.vala, in the GIOChannel read callback that streams rsync output. Reproduce on aarch64 or by simulating an immediate EOF on the child's pipe, then check whether the watch returns false (G_SOURCE_REMOVE) when read returns 0. Done means the parent exits after rsync finishes and info.json is written; the root cause is not yet confirmed.

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

Descrizione

Describe the bug
When running scheduled or scripted backups via timeshift --create, the underlying rsync execution script completes cleanly with an exit code of 0. However, the parent timeshift process hangs indefinitely, consuming 100% of an ARM core thread. It never writes info.json, leaving the snapshot unregistered and vulnerable to automated purging on subsequent runs.
Running an strace on the stuck parent process PID reveals an unhandled infinite spin loop querying a closed pipe descriptor at End-of-File (EOF):

[pid 6122] read(6, "", 1048576) = 0
[pid 6122] read(6, "", 1048576) = 0
[pid 6122] read(6, "", 1048576) = 0
... (repeats indefinitely)

To Reproduce
Steps to reproduce the behavior:

  1. Run timeshift cron job

Expected behavior
Timeshift completes and registers backup

System:
• OS: Fedora 44 (aarch64 / Raspberry Pi Server)
• Kernel: 7.2.x (Previously functioning normally on Fedora 43 with Kernel 7.1.x)
• Application Version: timeshift 25.12.14 (RSYNC mode)
• Core Libraries: glib2 >= 2.88

Root Cause Analysis:
The issue seems to lie in src/Core/AsyncTask.vala. When AsyncTask sets up asynchronous standard output/error monitoring streams (GIOChannel) to track rsync progress metrics, it handles stream boundaries interactively.
Apparently, under the newer Kernel 7.2 task scheduler and GLib 2.88 on weakly ordered memory architectures (aarch64), the child execution process terminates and its pipe write-end closes rapidly. This immediate closure forces the kernel to yield 0 bytes on the read end instantly. Because the Vala-compiled async loop lacks a hard escape/break condition specifically checking for bytes_read <= 0 or missing the G_SOURCE_REMOVE return callback signal when an empty read hits a non-blocking stream, the application loops infinitely on the same descriptor without ever reaching the downstream finalization sequences (such as writing info.json or unmounting temporary targets).

This issue appears to be heavily architecture/timing dependent, as an identical deployment of timeshift 25.12.14 on an x86_64 architecture running Fedora 44 / Kernel 7.2 executes cleanly without encountering the race condition.

Suggested Code Location for Patching:
The infinite loop occurs within src/Core/AsyncTask.vala inside the asynchronous IOChannel/DataStream channel read callback routines. The stream watch needs an explicit break statement or should return false (G_SOURCE_REMOVE) whenever bytes_read <= 0 or an EOF status condition is encountered, preventing GLib from continuously refiring the empty read event on aarch64.

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 Operating Systems

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.