Comments (22)
Yep, I can reproduce it as well. Not sure what's going on, it's worth checking with strace
what's the difference between the two invocations.
from host-spawn.
Attaching them now, I'll try to check when I have some time 😄
strace-flatpak-spawn.log
strace-host-spawn.log
from host-spawn.
I think you probably did strace host-spawn xdg-open
, while it would help to have the output of host-spawn strace xdg-open
instead, to see what's going on on the host side of the invocation.
I'll check what's going on as well.
EDIT: nevermind, xdg-open
is a bash script. No need for any strace.
from host-spawn.
OK, I've trimmed this down to gio
behaving differently.
host-spawn gio open http://google.com
doesn't do anything, while it works with flatpak-spawn --host
from host-spawn.
Interesting, might be worth comparing the strace for both then
from host-spawn.
Here's what I've found so far: gio open URL
doesn't work with host-spawn because there's a pty attached. gio open FILE
works, and the URL invocation works if I disable the pty but just pass stdin, stdout and stderr as-is to the process, like flatpak-spawn --host
does.
A broken invocation shows this line on the host journal:
Started app-glib-org.mozilla.firefox-28359.scope - Application launched by gio open.
while a working invocation shows:
Started app-glib-org.mozilla.firefox-28359.scope - Application launched by gio open.
Started app-flatpak-org.mozilla.firefox-28359.scope.
so in fact Firefox gets spawned in all cases, but the second scope doesn't get started, for some reason. I am doubtful this is a host-spawn bug itself, or rather if it is a gio
, a firefox
or a flatpak
bug.
I struggle to understand why attaching a pty would cause a problem with that program only.
from host-spawn.
@89luca89 is your browser installed as a Flatpak? Do you have the same problem if you configure your DE to default to another/ a non-Flatpak browser?
host-spawn gio open FILE
works and spawns gnome-text-editor on my host, which is a flatpak. So I don't know if it's browser related or what.
from host-spawn.
Yep all flatpaks, but if that works with gedit (which is flatpak) it shouldn't be flatpak related
It works with a native app (nautilus - host-spawn gio open .
) and a flatpak app (gedit - host-spawn gio open README.md
)
EDIT: Interestingly it does not work for videos or images either
from host-spawn.
Indeed, removing pty attachment, makes it work
Might be worth considering a --pty
flag to make it optional?
Better yet, it's the fds
setup in line 76 that is causing this issue
EDIT: specifically, it's the STDIN, setting it to host's stdin, breaks a possible shell, but makes gio work
fds := map[uint32]dbus.UnixFD{
0: dbus.UnixFD(os.Stdin.Fd()),
1: dbus.UnixFD(os.Stdout.Fd()),
2: dbus.UnixFD(os.Stderr.Fd()),
}
with this gio/xdg-open works, but spawning a shell will not work
from host-spawn.
I keep thinking this is an upstream issue. host-spawn
works fine with host-spawn strace -ff gio open http://combo.cc
, which makes me think this is a timing issue, as strace following every single fork() would slow down the gio
process considerably.
There is indeed a long standing bug about GLib/DBus dropping messages if the sender terminates too quickly. In this case the sender is gio
, which spawns your browser through DBus, but terminates very quickly so the spawning doesn't complete. Why this happens when we pass a pty, is anyone's guess and I'm really inexperienced with both dbus and glib to know exactly what's going on.
These might be relevant:
- https://gitlab.freedesktop.org/dbus/dbus/-/issues/72
- https://gitlab.gnome.org/GNOME/glib/-/issues/762
- https://github.com/GNOME/glib/blob/c1eb93d2a264372f35f140fef3777aea20595f71/gio/gdesktopappinfo.c#L3338
In fact I tried a small hack by keeping gio open
around instead of immediately returning (by literally duplicating this line https://github.com/GNOME/glib/blob/28fd2e4e67513fbbc45395ca717ae4d6dab268b6/gio/gio-tool-open.c#L133). In this case host-spawn
works as intended.
We need someone that knows dbus and/or glib pretty well to figure out what's going on, but as those issues mentioned above point out, there are corner cases in which the sender of a dbus message quits early and everything breaks.
from host-spawn.
Opened an upstream issue: https://gitlab.gnome.org/GNOME/glib/-/issues/2695
from host-spawn.
Might be worth considering a --pty flag to make it optional?
I would add a --no-pty
optional flag instead. This seems to be a problem strictly with gio
, and unless we can reproduce with another non-GLib tool, I think defaulting to creating a pty for the child process to be much more beneficial.
Still, I hate the idea of requiring one to pass --no-pty
only for this corner case to work. Let's sleep on this for a while to see if we can track down exactly what's going on.
EDIT: more test cases:
host-spawn sh -c 'gio open http://google.com'
doesn't workhost-spawn sh -c 'gio open http://google.com; sleep 1'
works
Ugh.
from host-spawn.
Yea as a workaround I was trying adding some "sleep" to make it wait for gio:
adding at line 36:
command := strings.Join(args[:], " ") + "; sleep 0.5"
args = append([]string{"sh", "-c"}, command)
makes it work as expected, but it's a really ugly workaround, probably it's better a --no-pty
flag for now
from host-spawn.
@1player for now I've opened a PR to add the --no-pty flag, at least as an host-spawn
user I have a way to work around it 😄
from host-spawn.
More debugging log: the reason it fails with host-spawn
and its pty is because somewhere down the line after gio
has spawned a browser, something closes the pty file descriptor and a sh
process terminated with SIGHUP. Of course doesn't happen with flatpak-spawn because SIGHUP is sent iff a tty is closed.
How to reproduce:
- On the host attach a gdb instance to your
flatpak-session-helper
process:gdb -p $(pgrep -f flatpak-session-helper)
- gdb:
set follow-fork-mode child
and thencontinue
- Run host-spawn on another shell
With host-spawn you'll get this output:
[Attaching after Thread 0x7f8cb3323c40 (LWP 3380) fork to child process 19442]
[New inferior 2 (process 19442)]
[Detaching after fork from parent process 3380]
[Inferior 1 (process 3380) detached]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
process 19442 is executing new program: /usr/bin/gio
[...cut a dozen lines...]
process 19455 is executing new program: /usr/bin/bash
Thread 4.1 "sh" received signal SIGHUP, Hangup.
[Switching to process 19455]
Whereas with flatpak-spawn --host, since they don't pass a pty, the SIGHUP will never happen. The question now is figuring out who and why is our pty fd closed as that stage, causing that SIGHUP to be fired.
from host-spawn.
I think there might be some problems with the pty creation/initialization then
because If I move it outside of the runCommandAsync
function, like this in the main
:
pty, err := createPty()
if err != nil {
log.Fatalln(err)
}
pty.Start()
defer pty.Terminate()
_, exitCode, exited := runCommandSync(os.Args[1:], pty)
it completely scrambles the host's terminal
from host-spawn.
No, the pty creation is fine. The scrambling is due to stdin set to RAW mode in pty.Start()
, which is in fact required to some host programs to work correctly.
Alright I've spent most of my day on this and I conclude that it's not a host-spawn bug yet I don't even know if it's possible to fix.
What is going on
- The host command gio/xdg-open gets spawned, with its stdin/stdout and stderr attached to a pty.
gio
becomes controlling process of that pty. - gio/xdg-open returns immediately, but behind the scenes it's still spawning processes, still attached to those pty file descriptors.
- Inside the container we have no way of knowing this, we get the HostCommandExited signal and we terminate.
- As we terminate, all our fds get closed, including the pty master fd. This causes the kernel to send a SIGHUP to whoever is the controlling process of that pty (should be gio/xdg-open or one of its child processes, but I'm not sure at this point)
- SIGHUP is not handled nor ignored by this controlling process, so the process is killed.
Why flatpak-spawn --host
is fine
They do not allocate a pty, so when HostCommandExited is sent prematurely, they too close their fds, but as they do not allocate a pty, the host side couldn't become the controlling process, so no SIGHUP is sent by the kernel.
Who exactly is at fault
I suspect the fault is of gio
, that terminates before it has actually spawned the web browser process. We have no way of dealing with this from inside the container. The only way we can mitigate it is with that --no-pty
hack.
Additional reading: http://www.linusakesson.net/programming/tty/index.php
I will merge your PR, but leave this open because there is a bug somewhere, but it's not on this side.
from host-spawn.
Fine for me, having a workaround for now, is also good in optic of upstream fix (that takes quite a while to come downstream)
from host-spawn.
@89luca89 this just dawned on me, but why are you running xdg-open
through host-spawn? It runs fine as-is inside distrobox, since the container shares the same DBus session as the host machine.
So, instead of doing host-spawn xdg-open http://google.com
, you can just do xdg-open http://google.com
.
For this reason I'm closing this issue. There is no need to use host-spawn
for that command.
from host-spawn.
@1player i'm fine with this, being an upstream bug, at least having the no-pty flag suffices 👍
from host-spawn.
BTW, I was following the upstream gio thread about this issue, and it might've been fixed with a recent release (which would fix it for most apps using GLib).
https://gitlab.gnome.org/GNOME/glib/-/issues/2695
I haven't had the chance to test yet.
from host-spawn.
Interesting, let's see how fast it trickles down to downstream 😄
from host-spawn.
Related Issues (20)
- Split the code into a library and binary to enable toolbx integration HOT 3
- no output in pty mode if stdin is redirected
- Consider defaulting to `--no-pty` for some programs
- Add vendor tarball for releases HOT 2
- How to use HOT 6
- `-env` should only propagate env var if it's set
- Forward signals via HostCommandSignal HOT 2
- Recursive call when shim symlink is in PATH on host HOT 2
- The name org.freedesktop.Flatpak was not provided by any .service files HOT 2
- Dev Container initialization getting stuck with VSCode Flatpak + Podman
- request to submit to Flathub as an extension
- Release assets should be signed HOT 5
- host-spawn doesn't terminate if pty is closed HOT 1
- Write better documentation HOT 2
- Does not work properly when used within Visual Studio Code HOT 5
- Create build script for targeting single architecture HOT 1
- Tags should have v prefix HOT 2
- Shim host binaries when symlinked
- RFE: Default to running shell if no command provided HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from host-spawn.