Process hangs around after closing last window with 'Destroying EGL context'

[jorismak]

Linux, Ubuntu 24.04, Wayland.

I'm starting ghostty from another terminal now to set things up, and I notice that the last line in the terminal is 'Destroying EGL context', and then the ghostty process just hangs there.

I've changed the quit-after-last-window-closed option to true in the config to make sure it quits, but it still stays around.

So, I have a global keybind on my system that starts a terminal (ctrl-alt-T), and then when I close the process, it stays around without windows. So every time I start a new terminal to get a window, I spawn a new process that stays around forever.

I fixed that now by forcing gtk-single-instance mode to true, that way no new processes will be spawned.
But the ghostty process not being able to exit and requiring a CTRL-C / break seems weird.

[isgj]

To add something here, also when you open it from the menu a similar behavior happens.
When you click the close window button, it asks that all the sessions will be terminated, after confirming (clicking yes), the window is closed and the process is terminated.

If you press CTRL-D (which I happen to use a lot), the window will be closed but the process will hang.

[jorismak]

Ha, you're right.
(Disabled gtk-single-instance for testing)

Closing the window by clicking the X (as in, closing through the window manager) exits with:

Destroying EGL context
Destroying EGL context
info(io_exec): read thread got quit signal
info(surface): surface closed addr=24c85c30
info(sentry): sentry envelope does not contain crash, discarding

...and really exits the ghostty process.

Pressing CTRL+D in the last window (or just typing exit) exits with:

Destroying EGL context

...and then just hangs there.

[lokesh-krishna]

I have .desktop entries to launch certain programs in ghostty with ghostty -e <app-name>. Whenever I launch one of these, from an existing terminal or a launcher, using my window manager's quit keybinding just has it hanging. If I launch it from a terminal then the message it hangs on is:

Destroying EGL context
Destroying EGL context

[lokesh-krishna]

Logs when launching senpai with ghostty -e senpai and quitting using the /quit command in senpai: log

Logs when quitting using my window manager's keybinding or ghostty's quit action with a keybinding: log

[lokesh-krishna]

Has anyone found any workaround to this? I'm confused about whether this is not an issue because the problem hasn't been described well enough or if this is somehow expected behaviour.

[lokesh-krishna]

Using the -e flag seems to automatically disable gtk-single-instance so not even sure how to workaround it :(

[morph027]

I agree....this is sort of a "bug", but not critical one. I mean, normally i do not close the terminal anyway, because of....you knowm work to be done 😂

[basile-henry]

This is a bug that I have been encountering as well. I thought it was more Ctrl-D related, and I hadn't seen this discussion so I contributed to this discussion instead: #3596

I can work around it, by enabling gtk single instance

I ended up figuring this out as well, and since it doesn't leak processes as much this way it's fine as a workaround, but I think this needs a proper fix.

I'm not entirely sure these discussions work as well as normal issues 😅

As long as it is known, eventually

I hope so 🤞

[pgmac]

I've been experiencing this same behaviour, too. IE:

• "hanging" when using CTRL-D or typing "exit".
• Exiting normally when clicking the "X" on the window title bar.

I tried using the GTK single instance, but that behaved the same for me and doesn't really work for my use case. I create and exit many terminals throughout (to execute commands and/or SSH connections).

This is on my Ubuntu 24.04 LTS laptop.
I've compiled the binary (using docker) in Ubuntu 24.04 and 24.10. Aside from different versions of GTK at runtime, both behave the same.

I also compiled using a RHEL docker image, as another person I know was able to use this on their (Asahi Linux) system.

Right now, I suspect this might be an Ubuntu OpenGL implementation/integration thing. But I don't know how to further investigate/debug this deeper.

I'm also using Gnome Shell. I haven't tried any other window managers. I don't know if that would make any difference, but it might be worth looking into. Just trying to rule out any other variables.

[jorismak]

That threat at least seems to indicate it's not a Linux only issue, which helps in my mind.

Why these issues get 'demoted' to discussions (this is how it feels to me at least ) I don't know, but as I said, I'm not going to limit my experience 😉.

[goonzoid]

It's possible that this might be fixed by #4605, but I don't have easy access to a Linux machine to test on right now. If someone feels like checking out my fork and giving it a try, that might be illuminating.

[slovdahl]

Doesn't seem to work very well on at least Ubuntu 24.04 right now: #4605 (comment)

[goonzoid]

I'm now pretty convinced that this is a different issue than the one #4605 fixes, fwiw.