Use systemd as subreaper

[R1kaB3rN]

Intended to be merged after 0.1 release, this pull request changes the subreaper from Valve's Reaper to systemd to reap spawned processes after a game is launched and exits.

When systemd is used as a subreaper process, a user-scoped transient unit will be created to reliably track/control all of the processes created at launch and to, optionally, manage their system resource usages (which is how Flatpak uses it). Systemd relies on Linux Control Groups (cgroups) to accomplish this, and all processes in the unit will be logically grouped together in a hierachical tree.

For clients, this means reaper does not need to be compiled on the system, eliminating the potential glibc locks when distributing reaper to old distributions, and all spawned subprocesses in that cgroup that fork/detach (e.g., winetricks) can reliably be killed. In addition, the entire process tree created after launching a game can be easily managed and monitored by the user via systemctl.

For example:

> systemctl status --user run-rc87623c08463475fbda10b1cc575cb38.scope;
● run-rc87623c08463475fbda10b1cc575cb38.scope - UMU_ID=1829980
     Loaded: loaded (/run/user/1000/systemd/transient/run-rc87623c08463475fbda10b1cc575cb38.scope; transient)
  Transient: yes
     Active: active (running) since Sun 2024-04-21 20:45:11 PDT; 3min 33s ago
      Tasks: 136 (limit: 18376)
     Memory: 1.7G (peak: 1.7G)
        CPU: 3min 33.516s
     CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/run-rc87623c08463475fbda10b1cc575cb38.scope
             ├─18064 /home/foo/.local/share/umu/pressure-vessel/bin/pv-bwrap --args 21 /usr/lib/pressure-vessel/from-host/bin/press>
             ├─18122 /usr/lib/pressure-vessel/from-host/bin/pressure-vessel-adverb --generate-locales --fd 12 --regenerate-ld.so-cache >
             ├─18220 /home/foo/.local/share/Steam/compatibilitytools.d/GE-Proton9-4/files/bin/wineserver
             ├─18224 "C:\\windows\\system32\\services.exe"
             ├─18227 "C:\\windows\\system32\\winedevice.exe"
             ├─18237 "C:\\windows\\system32\\winedevice.exe"
             ├─18250 "C:\\windows\\system32\\plugplay.exe"
             ├─18256 "C:\\windows\\system32\\svchost.exe" -k LocalServiceNetworkRestricted
             ├─18268 "Z:\\home\\foo\\Games\\cafe-stella\\CafeStella.exe"
             ├─18270 "C:\\windows\\system32\\explorer.exe" /desktop
             ├─18277 "C:\\windows\\system32\\rpcss.exe"
             └─18287 "C:\\windows\\system32\\tabtip.exe"

Apr 21 20:45:11 archlinux systemd[709]: Started UMU_ID=1829980.

This unit can be closed via systemctl stop --user run-rc87623c08463475fbda10b1cc575cb38.scope from the CLI or getting the invocation ID from systemctl list-units --user -o json by its UMU_ID then stopping the unit by its name.

Subreaping via systemd will not apply to the umu Flatpak as Flatpaks apply the --die-with-parent option by default, and already uses transient scoped units internally to accomplish the same effect.

[loathingKernel]

I am fully supportive of using and defaulting to systemd-run, but I am against completely removing reaper. IMO reaper should be present as a fallback.

[R1kaB3rN]

I am fully supportive of using and defaulting to systemd-run, but I am against completely removing reaper. IMO reaper should be present as a fallback.

I'm actually have different thoughts about this, so I will close this. I think this will only be really useful if users want to apply limits or restrict capabilities to the subprocess and there is currently no use case for that. In comparison, the same effect can be achieved by building reaper into the launcher itself or using pressure-vessel-adverb --subreaper.

The former is much simpler, so I plan to just implement that instead and get rid of the reaper stuff.