- Dec 17, 2020
-
-
Simon McVittie authored
To work around older versions of GLib having a potential deadlock in their fd-closing code due to use of non-async-signal-safe functions in the forked child process, the Flatpak-derived code we're using here uses a simple, naive implementation of closing fds: it iterates through every possible fd, up to the rlimit. Unfortunately, Wine users sometimes set their fd rlimit very high (typically around a million), because the "esync" mechanism in Proton's Wine needs a lot of fds. The time taken by each individual syscall is not significant, but when we do a million of them, it adds up. This is arguably a misconfiguration - the recommendation is now to have a soft rlimit of 1024 and a hard rlimit of about a million, so that only processes that opt-in to dealing with a million fds have to be aware of them - but a significant number of misconfigured systems probably still exist. We don't actually *need* to close all the fds here: there's no security boundary, so giving the child access to unnecessary fds isn't a privilage gain; the parent process outlives the child, so leaking fds won't result in them never being closed; and in any case we're reasonably careful to set CLOEXEC on all our fds. So let's just not close them. In particular, this can save literally a million syscalls per helper subprocess invocation (it's not often I get to say that!), reducing pressure-vessel-wrap launch time by 90% on a system with the high fd limit (about 70 seconds down to 7). With the recommended soft limit of 1024, the speedup is less dramatic, but it still takes off nearly 10% (about 6 down to 5.5). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/323 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 22, 2020
-
-
Simon McVittie authored
Now that GIO_MODULE_DIR has been backported into scout's GLib, we can disable GIO modules completely, instead of loading them but then not using them. This avoids some misleading warnings (#32). This will not be completely effective on non-Debian systems until we also patch scout's GLib to make GIO_MODULE_DIR take precedence over the hard-coded legacy search path /usr/lib/gio/modules. The unit test for this is still in tests/pressure-vessel/utils.c for now. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 06, 2020
-
-
Simon McVittie authored
We can use this to run other helpers, such as ldconfig. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means we can modify our own environment without affecting child processes. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We want to reinstate the old signal mask unconditionally, but we only want to throw an error for it if we weren't already about to throw an error. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 28, 2020
-
-
Simon McVittie authored
This avoids duplicating it in the command-line tools. The test is still in tests/pressure-vessel/ for now, because it needs testutils.py, which uses its own location to find G_TEST_SRCDIR. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 25, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 09, 2020
-
-
Simon McVittie authored
This is preparation for combining pressure-vessel with steam-runtime-tools. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 08, 2020
-
-
Simon McVittie authored
This is similar to how we deal with stdout, but for fds that have been passed through, other than stdin (0), stdout (1) and stderr (2). Part of pressure-vessel#6. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 07, 2020
-
-
Simon McVittie authored
Looking at environment variables is still part of pv-wrap, but the command-line part now happens in pv-adverb. This means the launching scripts for the "session" mode, which use pv-launch to run the main game command in a previously-set-up pv-launcher environment, can direct pv-adverb to run an interactive shell instead of or in addition to the actual game. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 04, 2020
-
-
Simon McVittie authored
When we have more than one layer of adverbs, this provides a way to tell which one we are. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes it a little clearer when we're exiting. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 18, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
-wrap eventually replaces itself with bubblewrap. If the bubblewrap process is killed, we want the adverb command to be terminated, passing the termination signal on to its own child process. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us have the following logic when sharing a container between multiple commands using -launcher and -launch: * For setup commands, don't wrap the launched command in the adverb. If the setup command starts background processes, they'll continue to run. This matches how installscript commands have historically worked for Windows (and Wine/Proton) games in Steam: the setup command is launched with system(), and can leak background processes like wineserver. * For the main game, wait for all processes to exit, by wrapping the launched command in the adverb, with --subreaper only. This matches how native Linux games, and the main command of Windows/Wine/Proton games, have historically worked in Steam. * When all processes belonging to the main game have exited, the -launcher can exit, at which point the subreaper that wraps it can clean up any background processes from the setup commands. --terminate-idle-timeout can be used to wait a few seconds before sending SIGTERM, if desired. Because the adverb now blocks SIGCHLD, we need to unblock it before running the child process; otherwise the child process will inherit the blocked signal, breaking things like g_spawn_async(). 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>
-
- Aug 05, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 04, 2020
-
-
Simon McVittie authored
We want this to be as similar as possible to exec'ing the child process directly. Close the original stdout, so that if the child's stdout is a pipe from which a caller reads until EOF, we do not prevent EOF from occurring. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We want this to be as similar as possible to exec'ing the child process directly, so give it our stdin as its stdin. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 29, 2020
-
-
Simon McVittie authored
pv_avoid_gvfs() can print GLib debug messages, which would corrupt a structured stdout. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the wrapped command prints structured data to stdout, we don't want to corrupt its output stream. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As noted in Flatpak and in GNOME/glib!490, there is a bug in GLib < 2.60 where g_spawn_* can sometimes deadlock while closing fds in a multi-threaded application. Work around this by making the affected fds close-on-execute ourselves, much like Flatpak does. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will make it easier to debug things going wrong in the adverb, by inheriting --verbose or PRESSURE_VESSEL_VERBOSE from the wrapper. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This breaks the build with -Werror on Debian testing/unstable. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 21, 2020
-
-
Ludovico de Nittis authored
pressure-vessel-with-lock has been renamed to pressure-vessel-adverb because now it has more capabilities than just taking a lock. This change should help the environments that are not able to normally run `bwrap`, like if we are in a Docker container or in a Flatpak app. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jun 12, 2020
-
-
Simon McVittie authored
This lets us hold a fd to the parent directory open and resolve paths relative to it (see openat(2)). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 23, 2020
-
-
Simon McVittie authored
This makes us match how Flatpak includes it, which makes our versions of Flatpak files more similar. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 06, 2020
-
-
Simon McVittie authored
These more modern locks, introduced in Linux 3.15 and not yet included in POSIX, propagate across fork(), dup(), fd-passing etc. the way you'd expect: as long as at least one copy of the inherited or fd-passed file descriptor remains open, the lock remains held. This allows us to pass a lock fd to a child process across bwrap's fork-and-exec the way we were already trying to, and have it actually work. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 14, 2019
-
-
Simon McVittie authored
We can use this in the SteamLinuxRuntime depot to deploy and garbage-collect runtimes stored in tarballs. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-