1player / host-spawn

Run commands on your host from inside your toolbox or flatpak sandbox

host-spawn

Run commands on your host machine from inside your flatpak sandbox, toolbox or distrobox containers.

Originally started as a reimplementation of flatpak-spawn --host.

Recommended setup

Note: Distrobox already ships with host-spawn. You might be better served by using their wrapper distrobox-host-exec which runs host-spawn under the hood.

• Install host-spawn in a location visible only to the container. I recommend /usr/local/bin.
• Make sure it is executable with chmod +x host-spawn

How to use

• host-spawn with no argument will open a shell on your host.
• host-spawn command... will run the command on your host.

Run host-spawn -h for more options.

Creating shims for host binaries

If there's a process that you always want to execute on the host system, you can create a symlink to it somewhere in your $PATH and it'll always be executed through host-spawn.

Example of creating a shim for the flatpak command:

# Inside your container:

$ flatpak --version
zsh: command not found: flatpak

# Have host-spawn handle any flatpak command
$ ln -s /usr/local/bin/host-spawn /usr/local/bin/flatpak

# Now flatpak will always be executed on the host
$ flatpak --version
Flatpak 1.12.7

Note: you will want to store the symlink in a location visible only to the container, to avoid an infinite loop. If you are using toolbox/distrobox, this means anywhere outside your home directory. I recommend /usr/local/bin.

Improvements over flatpak-spawn --host

• Allocates a pty for the spawned process, fixing the following upstream issues: flatpak/flatpak#3697, flatpak/flatpak#3285 and flatpak/flatpak-xdg-utils#57
• Handles SIGWINCH (terminal size changes)
• Passes through $TERM environment variable
• Shims host binaries when symlinked, see section above

host-spawn's Issues

Recursive call when shim symlink is in PATH on host

I have installed host-spawn at ~/.local/bin/. It is in PATH. At the same directory I've created symlink to shim flatpak:

$ ls -l .local/bin/
total 3552
lrwxrwxrwx. 1 paul paul      10 Mar 13 14:58 flatpak -> host-spawn
-rwxr-xr-x. 1 paul paul 3631750 Feb 18 20:43 host-spawn

When I run flatpak, it hangs for a second and fails:

$ flatpak list
read unix @->/run/user/1000/bus: EOF

I suspect that host-spawn tries to launch flatpak binary, but finds ~/.local/bin/flatpak -> host-spawn in PATH and launches another instance of host-spawn, thus making a recursive call, which never ends.

Release assets should be signed

Can you provide a detached signature of the binaries when doing releases?

Forward signals via HostCommandSignal

Signals received from the host-spawn side should get sent to the host command using HostCommandSignal: https://docs.flatpak.org/en/latest/libflatpak-api-reference.html#gdbus-method-org-freedesktop-Flatpak-Development.HostCommandSignal

Right now if I spawn a process on the host and send signals, the host side never receives them. I believe this is the issue but not 100% sure.

Create build script for targeting single architecture

Sometimes, there might be need to build host-spawn for single architecture. The good example is to build it within FlatHub pipeline. Currently, I am working on porting TheIDE to flatpak that is heavenly basing on host-spawn. One of the comments from the maintainers I received is can I build it instead of download pre-build binary package?

So, I assume we need something like ./build-host-platfrom that will generate binary in the host os operating system and architecture.

Reference:

• https://github.com/flathub/flathub/pull/4778/files#r1425341594 - my discussion with FlatHub maitaners and suggestion about building host-spawn from scratch during FlatHub CI/CD.

host-spawn doesn't terminate if pty is closed

Steps to reproduce

• Run host-spawn to open a shell on the host inside a terminal window
• Close terminal window
• Notice that host-spawn is still running

Write better documentation

The README was written when host-spawn was only a proof-of-concept, to demonstrate the issues in flatpak-spawn --host were relatively easy to fix. Now that it's starting to be used as a replacement of flatpak-spawn itself, it's better to rewrite the docs to explain how it works and how to set it up.

Does not work properly when used within Visual Studio Code

I'm trying to use fish inside the flatpak vscode, however it just exits after a few seconds without any error. Running bash or zsh works fine though, is there a way to debug the issue?

sh-5.1$ /run/host/usr/local/bin/host-spawn fish
[227 preload-host-spawn-strategy] Warning: waitpid override ignores groups
[227 preload-host-spawn-strategy] Warning: waitpid override ignores groups
sh-5.1$

The name org.freedesktop.Flatpak was not provided by any .service files

Hi! I'm using distrobox and want to run podman inside my containers. I followed your guide but I still end up with:

The name org.freedesktop.Flatpak was not provided by any .service files

Any idea what I'm missing? If it helps, I'm on openSUSE MicroOS. Any guidance would be greatly appreciated!

Ability to set Working Directory of Child Process

It would be nice if it was possible to set the working directory of the child process like is possible with the --directory parameter of flatpak-spawn.

RFE: Default to running shell if no command provided

If no command was provided, default to running the user's shell, similar to ssh. It could parse it from getent passwd $UID in host context and if it encounters an error, just fallback to /bin/sh.

handle and passthrough SIGWINCH

request to submit to Flathub as an extension

Hey, I am writing to inform you that I am submitting your software to Flathub as a vscode extension as I must confirm that:

I am an upstream contributor to the project. If not, I contacted upstream developers about submitting their software to Flathub.

Host `env` randomly breaks

First off, I'm honestly not sure if this is actually a host-spawn issue, an issue with the flatpak helper, or something dumb with my setup.

The main issue: occasionally when run from a distrobox, host-spawn env returns minimal entries. No DISPLAY/WAYLAND_DISPLAY, no XDG_SESSION_*, etc. You can see both envs in the attached straces.

Context: I have a few distrobox containers that I use for most of my day-to-day stuff, with several aliases and symlinks for running host commands (podman, flatpak, vscode, etc.). Everything works great for the most part, until it suddenly breaks again. It took a while to narrow down what the actual issue was, the main problems I would have were GUI apps (like vscode) not wanting to launch because they couldn't find DISPLAY. And env within the distrobox itself shows up fine, so running GUI apps installed within the distrobox works. It's only when trying to host-spawn something that I have this issue.

It's also a tough issue to diagnose because I can't figure out for sure how to trigger it to break, or how to fix it once it's broken. Deleting/recreating the distrobox doesn't usually help, though I did see it fix itself earlier after deleting the distrobox, fully logging out of my Plasma session, then logging back in and recreating the distrobox.

Doing a diff on the strace logs, the thing that stuck out the most to me is the epoll_pwait on line 193 in both files. From that point, things go in fairly different directions.

Like I said, not sure it's even an issue with host-spawn itself. It could easily be something dumb I'm doing or missing in my .profile/.bashrc, or something else set up funky on my machines. Just figured I'd ask here to see if you've seen anything like this, or had any ideas of where to look.

host-spawn-broken.log
host-spawn-working.log

Consider defaulting to `--no-pty` for some programs

Some processes executed through host-spawn fork, start other processes and terminate early. When they terminate, we close the pty and, due to how TTYs work, that might cause the process at the end of the spawn chain to be killed.

I do not think there's anything we can do on our side, and I'm wondering whether we should consider to default to --no-pty when we're executing binaries that are known to fork and return immediately, while retaining the default behaviour for everything else.

List of known binaries that cause issues and require --no-pty:

• xdg-open (see #7)
• flatpak run (reproducible with flatpak run net.runelite.RuneLite)
• anything else?

A implementation of this would be to keep a list of problematic binary names, and based on the command line args, decide whether a pty is appropriate or not. A user might override our heuristic by explicitly passing a --pty or --no-pty option.

Fix UX by adding --help and better error messages

no output in pty mode if stdin is redirected

Unless --no-pty is passed, there is no output if stdin is redirected. I'm not even sure if the command is even executed in the first place.

$ host-spawn echo foo 
foo
$ host-spawn echo foo </dev/null
$

Expected result

$ host-spawn echo foo 
foo
$ host-spawn echo foo </dev/null
foo
$

refactor pty code

Try to avoid cgo if possible

`-env` should only propagate env var if it's set

I expected -env to no-op if the variable isn't set. But it looks like it still defines the variable and sets its value to the empty string:

$ host-spawn -env NONEXISTENT_VAR env | grep NONEXISTENT_VAR
NONEXISTENT_VAR=

Split the code into a library and binary to enable toolbx integration

One option to add this directly into toolbx upstream is to split the logic into a library that is pulled by toolbx and kept here for this binary.

xdg-open not working properly

Doing something like:

host-spawn xdg-open https://google.com

should open host's browser pointing at that page.
Right now, flatpak-spawn works, while host-spawn does not. This seems not related to anything in the env, right now doing

vimdiff <(host-spawn env | sort -u) <(flatpak-spawn --host env | sort -u)

shows no difference in the environment

How to use

It would be much appreciated if you could clarify how to use this. Beyond pulling it manually (which doesn't seem very stable or official) it would be nice if you could clarify the different ways of sourcing and installing it in a Flatpak.

figure out which env variables to pass to the spawned process

Right now we hardcode $TERM, which should probably be inherited along with other variables. See how Tilix does it.

Add vendor tarball for releases

For Flatpak builds, we do not have network access so it's much easier for us if we have a vendor tarball that we can pull in.

The idea is to run the following and add it to each release:

$ git clean -fdx
$ go mod vendor
$ tar --create --zst --file host-spawn-vendor.tar.zst

Tags should have v prefix

It looks like the tagging policy for this repo use non standard way to do in the context of GoLang world. So, instead of having 1.5.0 tag, there should be v1.5.0.

For example all of packages used in this project are using this convention:

• https://github.com/godbus/dbus - v5.1.0
• https://github.com/pkg/term - v1.1.0
• https://golang.org/x/sys - v.0.15.0

Dev Container initialization getting stuck with VSCode Flatpak + Podman

I'm trying to set up a Dev Container environment for my Fedora Silverblue installation, with VSCode Flatpak + Podman. I've provided a wrapper script for VSCode to spawn host-side Podman via command exec host-spawn podman "$@", but I've noticed that, although it builds the devcontainer properly, it gets stuck at some point when initializing it:

This problem does not occur when I pass option --no-pty to host-spawn podman, so I'm providing a PR to include podman to the list of binaries defaulting to --no-pty.

Shim host binaries when symlinked

Like 89luca89/distrobox#343 and containers/toolbox#145

$ ln -s /usr/bin/host-spawn /usr/local/bin/podman

Now running podman will be equivalent to running host-spawn podman