- Jun 14, 2022
-
-
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>
-
Simon McVittie authored
The FEX-Emu "rootfs" is conceptually just a /usr (plus parts of /etc and /var), just like the Steam Runtime. However, the rootfs versions that are currently distributed contain some files in /etc, /run and so on. When we open files with opendir() or access() or similar, FEX-Emu will transparently substitute files from the "rootfs" if they exist. However, when we're building up a list of bind-mounts for a root filesystem, this is counterproductive: bwrap will do the equivalent of `mount --bind /oldroot/run/foo /newroot/run/foo`, which is not going to work if /foo is really /home/me/.fex-emu/RootFS/Ubuntu_21_10/run/foo. For several categories of file, and in particular /run and other API filesystems, what we really want to do is to ignore the "rootfs" and take the files and directories from the real root. Because FEX-Emu's rewriting is path-based rather than identity-based, we can do this by looking up the paths relative to /proc/self/root. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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 set this up, we have to be able to distinguish between the two environments. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It'll be easier to pass this through transformations like adjust_exports() if we can know that everything in the new bwrap object was produced by pv_wrap_share_sockets(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When we add support for transparent emulation such as FEX-Emu, we'll need to carry out rewriting for bwrap arguments generated from the code we borrow from Flatpak. This will be easier to do if we support more of bwrap's command-line options. As before, we classify them by how many arguments they have, and which arguments are paths in the host system. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 01, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
runtime: Fix close() of potentially uninitialized fd See merge request !443
-
Ludovico de Nittis authored
pv-runtime: Really capture dependencies of captured drivers Closes #91 See merge request !442
-
- May 31, 2022
-
-
Simon McVittie authored
Detected by gcc 11. Fixes: 53f735d2 "pv-runtime: Add a fast-path for drivers that are symlinked or hardlinked" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-