Repository navigation
Logs can fill a disk without any control #3597
Description
Feature summary
An error loop may create a log every ms, ending up filling a disk
What problem are you trying to solve?
This is especially true on chromebook, it is quite random, but sometime when I come back and unlock my session, the process start logging "Audio output stream failed: a backend-specific error has occurred: alsa::poll() returned POLLERR" indefinitly (well unmutting the host sound make this disapears) but anyway the log size increase by 5Gb every minutes meaning the disk is full in a jiffy.
The log file with this issue is "github-app.{pid}.log".
Proposed solution
Would it be possible to limit the size of this file to let say 1Gb and make it rolling (keep 5 file maximum) + an alert "warning rolling log file, check why you have so many logs" .
Workflow impact
no need to clean file to continue working, warning on strange alert if there are.
Installation context
No response
Additional context
No response
Activity
KevinTCoughlin commentedon Oct 4, 2026
Same loop on desktop Linux, so it's not Chromebook-specific:
WARN github_app::platform::system_sounds: Audio output stream failed error=A backend-specific error has occurred: alsa::poll() returned POLLERR, repeated from 2026-10-03T21:44:57Z until the app exited ~5h latergithub-app.<pid>.logreached 770 GiB and filled the disk to 98%Likely root cause: the bundled cpal. Going by symbol names, the 1.1.23 and 1.1.25 Linux builds both use
rodio 0.21.1→cpal 0.16.0. In cpal 0.16.0, the ALSA output worker turnsPOLLERRinto aBackendSpecificError, calls the error callback, and polls again without recovering the PCM. POLLERR stays set while the PCM is in XRUN/SUSPENDED, sopoll()returns immediately and the worker spins, and each callback is logged at WARN.Fixed upstream in RustAudio/cpal#1122, released in cpal 0.18.0 ("Polling errors trigger underrun recovery instead of looping"). No rodio release includes it yet: rodio 0.22.x depends on cpal 0.17, and rodio
mainmoved to 0.18 in RustAudio/rodio#891 (unreleased). Upgrading to rodio 0.22 alone won't fix it.Separately, rate-limiting that log line and rotating
github-app.<pid>.logwould stop any future spin from filling the disk.gimenete commentedon Oct 18, 2026
The unbounded growth of
github-app.<pid>.logis fixed in current source. Each app log file is now capped at 64 MiB. When it reaches that limit, the app preserves the startup portion, writes a truncation marker and continues with recent entries at the same file path. If truncation fails, file logging stops instead of continuing to grow.This is a per-file limit, not a total across processes; startup cleanup still keeps the 20 newest app log files. It addresses the disk-filling log growth reported here, not the underlying Linux audio POLLERR loop or its CPU cost. It also does not limit unrelated runtime/process logs.
The fix is not in the latest verified stable release, v1.1.30. I have not yet verified a released version containing it. Closing the unbounded app-log growth request as implemented, with that release caveat.