Package: gnome-terminal Version: 3.51.90-1 Severity: normal Occasionally I run ffmpeg to transcode videos and this can take up to an hour. With the latest gnome-terminal, this long-running process gets stopped when the terminal is not visible. This can be because the frame shows another tab or because the window is minimized and thus not visible. Using strace I found that ffmpeg is blocked on outputting its progress report. These are the final lines of strace output (filtered for write), before ffmpeg is suspended:
write(2, "frame=44221 fps= 12 q=31.5 size= 358656kB time=00:30:45.83 bitrate=1591.8kbits/s speed=0.503x \r", 99) = 99 write(2, "frame=44228 fps= 12 q=31.2 size= 358656kB time=00:30:46.13 bitrate=1591.5kbits/s speed=0.503x \r", 99) = 99 write(2, "frame=44235 fps= 12 q=29.0 size= 358656kB time=00:30:46.43 bitrate=1591.2kbits/s speed=0.503x \r", 99) = 99 write(2, "frame=44243 fps= 12 q=29.1 size= 358656kB time=00:30:46.75 bitrate=1591.0kbits/s speed=0.503x \r", 99 As can be seen, the write call blocks (it does not finish) and ffmpeg is suspended. Bringing the tab to the foreground will resume processing and the output. Trying to reproduce this without ffmpeg, I came up with this little bash one- liner: i=0 ; while true ; do echo -e "Some counter $i" ; sleep .5 ; i=$(expr $i + 1) ; if [ $(( $i % 10 )) == 0 ] ; then echo -ne "\a" ; fi ; done This will beep every 5 seconds, so we know when the loop is still running fine. Just start it in the terminal and then minimize the terminal (switching to other tabs seem not to be a problem for this recipe). The beeps will stop immediately. After waiting a little while and refocusing the window, I see that the counter catches up to the correct value in regard to its start time, but that the output was not consumed anymore. Probably in this case, one needs to wait longer until a buffer fills up and then finally stops the shell loop. I guess this is what is happening with the ffmpeg process. But the test case should be good enough, as xterm running this one-liner continues to beep all the time, no matter if the terminal is minimized or not. As I did not have this problem previously, I believe it is a regression that has entered Debian Trixie in the last few weeks / months. -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.10-4 ii dbus-x11 [dbus-session-bus] 1.14.10-4 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1 ii gnome-terminal-data 3.51.90-1 ii gsettings-desktop-schemas 46.0-1 ii libatk1.0-0 2.50.0-1+b1 ii libc6 2.37-15 ii libgcc-s1 14-20240201-3 ii libglib2.0-0 2.78.4-1 ii libgtk-3-0 3.24.41-1 ii libhandy-1-0 1.8.3-1 ii libpango-1.0-0 1.52.0+ds-1 ii libstdc++6 14-20240201-3 ii libuuid1 2.39.3-6 ii libvte-2.91-0 0.75.91-2 ii libx11-6 2:1.8.7-1 Versions of packages gnome-terminal recommends: ii gvfs 1.53.90-2 ii nautilus-extension-gnome-terminal 3.51.90-1 ii yelp 42.2-1+b1 gnome-terminal suggests no packages. -- no debconf information
