Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Running makedeltaiso and it's running out of memory, so sd-oomd is clobbering the scope. The problem is that tmux is adding all the sessions to a single scope, so when oomd kills that scope it kills all of tmux and its sesssions. So tmux needs to learn how to put each shell into its own scope, similar to what GNOME Terminal already knows how to do. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. tmux, create a few sessions 2. in one of the sessions find a way to use up too much RAM like stress or makedeltaiso (what i'm doing) on two 2G ISOs on a 4G RAM system 3. Actual results: oomd clobbers the entire scope tmux is in, which includes all processes running in tmux Expected results: tmux should create a separate systemd scope for each pane/session/shell that gets started, so that those shell processes are running in their own cgroup, and thus can be independently killed by sd-oomd rather than taking down all sessions running in tmux Additional info:
On Fedora with GNOME, vte moves each process into its own scope, and thus its own cgroup assignment. This isn't happening for tmux processes. The code is here: https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/systemd.cc
Jan 02 20:08:10 fnuc.local systemd-oomd[648]: Killed /user.slice/user-1000.slice/session-9.scope due to memory used (3948032000) / total (4024205312) and swap used (3631742976) / total (40233820> Jan 02 20:08:10 fnuc.local systemd[1]: session-9.scope: systemd-oomd killed 7 process(es) in this unit. Jan 02 20:08:12 fnuc.local systemd[1]: session-9.scope: Deactivated successfully. Jan 02 20:08:12 fnuc.local systemd[1]: session-9.scope: Consumed 31min 21.423s CPU time. Jan 02 20:08:12 fnuc.local systemd-logind[692]: Removed session 9.
Nice idea but I don't think it does fit into tmux as a gerneric terminal multiplexer. Feel free to discuss with upstream @ https://github.com/tmux/tmux what their thoughts are. I will leave this ticket open for reference but I am not going to work on it.
I opened https://github.com/tmux/tmux/issues/3024 about it.
Following the upstream issue to see where that goes and will then update the package accordingly (assuming anything happens upstream with the request). Thanks.
FEDORA-2022-8985737e34 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8985737e34
FEDORA-2022-8985737e34 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-8985737e34` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8985737e34 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-8985737e34 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.