- Jun 14, 2022
-
-
Simon McVittie authored
This could be useful if we're routinely wrapping games in the launcher service: if that's the case, then we'll want to fall back to running the game without the launcher service if setup fails, rather than just not running any games until it's fixed. Resolves: steamrt/tasks#129 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This might make sense to be the default later, but for now it has to be requested explicitly. It currently only sets up com.steampowered.App1234. Additionally listening for ...App1234.Instance54321 could be added later if wanted. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This might be a useful way to have both per-app and per-instance bus names, for example com.steampowered.App1234 and com.steampowered.App1234.Instance54321 on the same server. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These can be used to make the command-launcher service linger after a game has exited. For example, if the game crashes too soon after startup to be able to attach a debugger, this allows it to be re-run. Resolves: steamrt/tasks#127 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This can be used to keep the launcher service alive even if it has been replaced by another similarly-named launcher, for example when using a well-known name per Steam game. Resolves: steamrt/tasks#128 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, the synopsis implied that --terminate was only allowed when not specifying a COMMAND, and the exit status description implied that `s-r-launch-client --terminate -- false` would exit 0 (in fact it propagates the exit status from false(1), and exits 1). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, both success and failure came out as exit status 125, contradicting the man page, which said a successful --terminate was exit status 0. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This exercises two recent changes: the launch-client binds to the launcher-server by its unique name, and the launcher-server doesn't exit while it has subprocesses running, even after losing its name. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of using a GMainLoop, it's often clearer what is going on if we explicitly loop until a condition becomes false, and that seems to be the case here. Keeping better track of the circumstances under which we exit revealed that if we lose our D-Bus name (due to being replaced by a second instance with --replace), we would have exited after a short delay. This seems unfortunate, because we don't terminate our child processes in that situation, but exiting from the launcher-service process means that the launch-client processes cannot be informed when the child processes exit or given the opportunity to send signals to them, even if they are tracking the launcher-service by its unique name (as we started to do in a previous commit). Resolve this by continuing to not terminate the child processes, but also lingering until they have all exited, so that we can propagate their exit statuses back to the caller if it is watching our unique name. Similarly, in signal_handler() and exit_on_readable_cb(), previously we would unconditionally stop the main loop immediately. Now, we wait for child processes to exit and for a possible queue of D-Bus calls to be processed. Related to steamrt/tasks#128 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the process we are terminating is not a process group leader, then killpg() will fail with ESRCH. This is particularly significant if we are terminating a wrapped process, for which we set `child_setup_data.keep_tty_session = TRUE` so that it will not give up its controlling terminal (if any). Before this change, `test_wrap_wait` in tests/pressure-vessel/launcher.py would leak its `sleep 600` subprocess, which was not correctly terminated by calling `s-r-launch-client --terminate`. Replace that with a `cat` subprocess so that we can detect when it has been terminated, and replace the previous use of stdout (which duplicated similar code in `test_wrap_info_fd`) to facilitate that. This will become more important when we keep better track of child processes in order to avoid exiting while there are still managed child processes running. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This wasn't particularly descriptive, and I now want to use the name pv_launcher_server_stop() for something else. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
With the `terminate-after` option, processes that make us exit are not necessarily the "main" process. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the launched process is run directly (as opposed to via a wrapper script that runs it as a subprocess or puts it in the background), then this is a convenient way to attach a debugging tool like strace or gdbserver to the launched process (typically a game). The `MAINPID` variable name is borrowed from systemd.exec(5). Note that for tools that ptrace the game (like gdbserver and strace), this will not work on Ubuntu or other distributions that use YAMA, unless you set sysctl `kernel.yama.ptrace_scope=0` to remove the restriction on debugging non-child processes. main_pid remains set even after the main process has terminated, because this gives us a way to keep track of whether the process we are looking at was the main process (which we will want in a subsequent commit to clarify the message when implementing `terminate_after`), and to keep track of whether the main process was ever run (which we will want for steamrt/tasks#129). Resolves: steamrt/tasks#126 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The launcher API is stateful: once we have asked an instance of the launcher to start a subprocess, we must send any subsequent Terminate() or SendSignal() messages to the original instance, not to a second instance that has taken over the same well-known bus name with `s-r-launcher-service --replace`. Similarly, we must listen for ProcessExited signals from the original instance, not a replacement. We can achieve this by resolving the well-known bus name (analogous to a DNS name) to a unique name (analogous to a dynamic IP address, but more so, since it is never reused during the lifetime of a dbus-daemon). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This bug was inherited from flatpak-spawn. Forwarded: https://github.com/flatpak/flatpak-xdg-utils/pull/59 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
tests: Make launcher-service tests more robust and more debuggable See merge request !448
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes it easier to find out what is timing out. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise, if they get stuck, nothing will happen until the global test timeout, at which point the output will be lost in some cases. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 13, 2022
-
-
Simon McVittie authored
Previously, we were doing a close(0) in the use_stdin code path, instead of closing the read end of the pipe to the subprocess's stdin as we should. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids corrupting machine-readable TAP stdout. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 09, 2022
-
-
Ludovico de Nittis authored
launch-options: Try to launch container runtimes via _v2-entry-point See merge request !446
-
Ludovico de Nittis authored
launch-options: Add control over STEAM_COMPAT_LAUNCHER_SERVER See merge request !445
-
- Jun 08, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is a closer match for what Steam does, and provides ancillary features like logging and STEAM_COMPAT_LAUNCHER_SERVICE. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
pv-runtime: Create /usr/share/defaults/etc/ld.so.conf, for Solus See merge request !444
-
- Jun 07, 2022
-
-
Simon McVittie authored
Solus' ldconfig is hard-coded to read this path as its default, rather than the /etc/ld.so.conf used in all other known distributions, in an effort to be able to run with an empty /etc. When Steam's LD_LIBRARY_PATH runtime runs inside a pressure-vessel container, it relies on ldconfig picking up the configuration that was set up by pressure-vessel, so we need this path to be a symlink to the location we have set up. Because this path is below /usr, it'll only work for the mutable-sysroot code path, but in practice that's the one that Steam uses in production anyway, so this limitation seems reasonable. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/510 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
By the time we're running bubblewrap, it's too late to modify /usr: we're going to mount it read-only, so writes will fail. However, in the configuration with a mutable sysroot (which is what we actually do in production), we can modify the mutable sysroot before that point instead. This code isn't used yet, but will be used in a subsequent commit. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Writing into other locations will either fail at runtime or modify persistent state, so don't even try. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is mostly just refactoring, but it introduces the concept that creating the symlink might fail. This can't actually happen in practice, because the only failure mode that is implemented right now is bwrap being NULL, which cannot really happen in these call sites. These alternate filenames won't be critical on most OS configurations, so if creating the symlink fails, we just warn and try to continue. The slightly odd error exit path will get more use in subsequent commits. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Translate FEX-Emu rootfs See merge request !433
-
- Jun 06, 2022
-
-
Simon McVittie authored
A common approach to transparent CPU-architecture emulation is to have an overlay with binaries for the emulated architecture, and transparently use those (as though they were an overlayfs over the real filesystem) when an emulated process accesses their paths. For example, FEX-Emu emulates x86 on aarch64 systems. When an aarch64 process opens an architecture-dependent file like /usr/lib64/libc.so.6 or /etc/ld.so.cache, it gets the real file; when an emulated x86 process opens an architecture-dependent file, if that file exists in the FEX-Emu "rootfs", FEX-Emu will transparently redirect the file access to the copy in the "rootfs". When we enter the Steam Runtime container, we need two environments inside the container: an aarch64 environment that can run the FEX-Emu interpreter itself, and an x86 environment that can run pressure-vessel-adverb, Steam Runtime executables, and the actual game. To arrange for this to happen, we can use a subset of the real aarch64 operating system as the root of the container, and set up a new FEX-Emu rootfs in /run/pressure-vessel/interpreter-root. This means that aarch64 executables in the Steam Runtime container see the real host OS, but x86 executables see the Steam Runtime. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The code we've borrowed from Flatpak to deal with things like X11 and D-Bus can find files and directories in either the real root filesystem, or the FEX-Emu rootfs. If we naively pass the paths it has discovered to bwrap, we'll find that they don't necessarily exist: for example, the minimal aarch64 system I'm using for initial testing of this code doesn't have /var/cache/fontconfig, but the rootfs does. This makes bwrap fail when it tries to bind-mount /oldroot/var/cache/fontconfig onto /newroot/var/cache/fontconfig. To avoid this failure mode, look up the paths in the rootfs, and if necessary rewrite them. For example, we can bind-mount /oldroot/$FEX_ROOTFS/var/cache/fontconfig onto /newroot/var/cache/fontconfig, and that will work fine. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We don't yet do anything with FEX-Emu thunks (substitute shared libraries that override certain real libraries), so we need to provide a complete x86 graphics stack, and the FEX-Emu rootfs is a good place to find one of those. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-