-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xdg-open not working properly #7
Comments
Yep, I can reproduce it as well. Not sure what's going on, it's worth checking with |
Attaching them now, I'll try to check when I have some time 😄 |
I think you probably did I'll check what's going on as well. EDIT: nevermind, |
OK, I've trimmed this down to
|
Interesting, might be worth comparing the strace for both then |
Here's what I've found so far: A broken invocation shows this line on the host journal:
while a working invocation shows:
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 I struggle to understand why attaching a pty would cause a problem with that program only. |
@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?
|
Yep all flatpaks, but if that works with gedit (which is flatpak) it shouldn't be flatpak related EDIT: Interestingly it does not work for videos or images either |
Indeed, removing pty attachment, makes it work Better yet, it's the 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 |
I keep thinking this is an upstream issue. There is indeed a long standing bug about GLib/DBus dropping messages if the sender terminates too quickly. In this case the sender is These might be relevant:
In fact I tried a small hack by keeping 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. |
Opened an upstream issue: https://gitlab.gnome.org/GNOME/glib/-/issues/2695 |
I would add a Still, I hate the idea of requiring one to pass EDIT: more test cases:
Ugh. |
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 |
This works around some problems with GIO, as seen in issue 1player#7 Specifying --no-pty will make `host-spawn` behave like `flatpak-spawn --host`. Signed-off-by: Luca Di Maio <luca.dimaio1@gmail.com>
@1player for now I've opened a PR to add the --no-pty flag, at least as an |
More debugging log: the reason it fails with How to reproduce:
With host-spawn you'll get this output:
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. |
I think there might be some problems with the pty creation/initialization then 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 |
No, the pty creation is fine. The scrambling is due to stdin set to RAW mode in 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
Why
|
Fine for me, having a workaround for now, is also good in optic of upstream fix (that takes quite a while to come downstream) |
@89luca89 this just dawned on me, but why are you running So, instead of doing For this reason I'm closing this issue. There is no need to use |
@1player i'm fine with this, being an upstream bug, at least having the no-pty flag suffices 👍 |
This workaround is needed because of a bug in gio (used by xdg-open) where a race condition happens when allocating a pty, leading to the command being killed before having time to be executed. https://gitlab.gnome.org/GNOME/glib/-/issues/2695 1player/host-spawn#7 As an (ugly) workaround, we will not allocate a pty for those commands. Signed-off-by: Luca Di Maio <luca.dimaio1@gmail.com>
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. |
Interesting, let's see how fast it trickles down to downstream 😄 |
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 doingvimdiff <(host-spawn env | sort -u) <(flatpak-spawn --host env | sort -u)
shows no difference in the environment
The text was updated successfully, but these errors were encountered: