Ghostty should not delay startup if dbus is unreasonably slow

[mitchellh]

Discussed in #4620

^{Originally posted by daveadams January 5, 2025}
Hello, I'm testing out Ghostty on Linux and I'm seeing an unusably long delay in opening the initial terminal window when starting ghostty on the order of one to two minutes. The logs indicate a timeout when querying DBus for the system theme.

There are other topics about "significant delays" but those seem to be on the order of a second or two rather than multiple minutes.

My system is Debian 12. I'm using Sway as my window manager, so Gnome services aren't fully available, which I suspect is the source of the problem.

Relevant log snippet (with timestamps added):

06:28:25 info: ghostty version=1.0.2-main+0306c592
06:28:25 info: ghostty build optimize=ReleaseFast
06:28:25 info: runtime=apprt.Runtime.gtk
06:28:25 info: font_backend=font.main.Backend.fontconfig_freetype
06:28:25 info: dependency harfbuzz=8.4.0
06:28:25 info: dependency fontconfig=21402
06:28:25 info: renderer=renderer.OpenGL
06:28:25 info: libxev backend=main.Backend.io_uring
06:28:25 info(os): setlocale from env result=LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=C.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8
06:28:25 info(gtk): GTK version build=4.8.3 runtime=4.8.3
06:28:25 info: reading configuration file path=/home/dadams/.config/ghostty/config
06:28:25 info(config): default shell source=env value=/bin/bash
06:28:25 info(gtk): libadwaita version build=1.2.2 runtime=1.2.2
06:29:40 error(gtk): unable to get current color scheme: Timeout was reached
06:29:40 info(grid): loaded OpenGL 4.6
06:29:40 info(font_shared_grid_set): font regular: DejaVu Sans Mono
06:29:40 info(font_shared_grid_set): font bold: DejaVu Sans Mono Bold
06:29:40 info(font_shared_grid_set): font italic: DejaVu Sans Mono Oblique
06:29:40 info(font_shared_grid_set): font bold_italic: DejaVu Sans Mono Bold Oblique
06:29:40 info(io_exec): found Ghostty resources dir: /home/dadams/src/github.com/ghostty-org/ghostty/zig-out/share/ghostty
06:29:40 info(io_exec): shell integration automatically injected shell=termio.shell_integration.Shell.bash
06:29:40 warning(gtk): unimplemented action=apprt.action.Action.Key.cell_size
06:29:40 warning(gtk): unimplemented action=apprt.action.Action.Key.size_limit
06:29:40 info(io_exec): started subcommand path=/bin/sh pid=155494
06:29:40 info(io_exec): subcommand cgroup=-
06:30:05 error(gtk): unable to get current color scheme: Timeout was reached
06:30:05 info(grid): reallocating GPU buffer old=0 new=38

You can see the 75 second delay between reporting the libadwaita version and the "Timeout was reached message" and a second time, there's a 25 second delay in the penultimate log line.

Watching dbus-monitor, I see a lot of business going on as the DBus lib tries various ways to get to the API it's trying to call to get the color scheme, but I think ultimately this is the meaningful error:

method call time=1736081549.289863 sender=:1.68 -> destination=org.freedesktop.DBus serial=41 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.freedesktop.IBus'"
method return time=1736081549.289893 sender=org.freedesktop.DBus -> destination=:1.68 serial=36 reply_serial=41
method call time=1736081549.289899 sender=:1.68 -> destination=org.freedesktop.DBus serial=42 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.freedesktop.IBus"
error time=1736081549.289906 sender=org.freedesktop.DBus -> destination=:1.68 error_name=org.freedesktop.DBus.Error.NameHasNoOwner reply_serial=42
   string "Could not get owner of name 'org.freedesktop.IBus': no such name"

So it's pretty clear to me that if the correct Gnome services aren't running, there's a massive delay in showing the initial window.

There are some config settings related to forcing a particular theme. I tried setting those to no effect. The code doesn't really have any branch points around fetching this setting, so I wasn't surprised. It would be nice to have an option to tell ghostty not to bother trying to talk to such specific services and just let me tell it what theming I want.

[Guigui220D]

I also found Ghostty very long to start on my own pc, only in the order of a second or two, but a lot slower than even gnome-terminal. I dont know if it's related.

[zsxawerdu]

Regarding this for WSL2 Users, I have the same issue on ubuntu 24.04 using WSL2.

However there seems to be a work around. Please note, the following command has to happen at the very start of the session, else it does not work immediately. Else wsl -t <Distro> and restart the console terminal.

ln -sf /mnt/wslg/runtime-dir/wayland-* $XDG_RUNTIME_DIR/

This fixes all slow GUI apps, not just Ghostty.

[FedeAbella]

Just got here cause I'm trying out ghostty on hyprland and found it a lot slower than kitty (my usual terminal). Same as above, it takes maybe a second or two to open, but by comparison that's incredibly slower than kitty.

Let me know if there's something I can provide to help debug this

[craighewetson]

I had the same problem, on River wm.
But after doing something on my system the problem is gone, so I am not sure what happened but maybe explaining what I did might give clues.

I looked if there were similar issues on sway wm. (not ghostty related but related to xdg-desktop-portal-gtk because i saw that in the error logs while ghostty was starting up)

I then found a suggestion to use dbus-broker (So I installed it and enabled the service via systemctl) this did not help and then subsequently disabled the service and remove the package.
But after restarting my machine, I discovered to my surprise the ghostty starts up fast (like most apps) on river.

I do get the following error in the logs that I didn't see before:

(process:3420): GLib-GIO-CRITICAL **: 09:28:04.784: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(process:3420): Gtk-WARNING **: 09:28:04.784: Unable to acquire session bus: Cannot autolaunch D-Bus without X11 $DISPLAY

Don't know if this helps anyone but maybe it will give hints to finding the proper solution

[munim]

I have been using Ghostty for a week now but it's quite slow to start. I use Tiling Window Manager, and its normal to open and close terminal. It has to be fast.

Unfortunately Ghostty is slow to start compared to other terminal.

[craighewetson]

I after my "hack" or accidental "fix", ghostty starts up instantly ...
Is there a command that I can give a number to what I mean by "instantly"?
Using time ghostty -- bash -c "exit" doesn't work

even if I use time (ghostty & sleep 1; pkill ghostty) I get time output of 1s 24ms ... and I know the 1 second is not ghostty but the sleep in the command.

[munim]

I after my "hack" or accidental "fix", ghostty starts up instantly ... Is there a command that I can give a number to what I mean by "instantly"? Using time ghostty -- bash -c "exit" doesn't work

even if I use time (ghostty & sleep 1; pkill ghostty) I get time output of 1s 24ms ... and I know the 1 second is not ghostty but the sleep in the command.

I have dbus-broker installed and enabled before I started using Ghostty. It is still slow compared to Alacritty/Kitty on startup.

[craighewetson]

my point was that installing and then removing it (dbus-broker) worked for me ... but I am not suggesting you should do that ... I am only giving feedback to help the developer to fix this problem.

(I am avoiding telling the dev what is already known and how bad the problem is )

[munim]

my point was that installing and then removing it (dbus-broker) worked for me ... but I am not suggesting you should do that ... I am only giving feedback to help the developer to fix this problem.

(I am avoiding telling the dev what is already known and how bad the problem is )

Apologies, I didn't mean any offense.

[Proximus888]

Only the first instance of Ghostty startups slow. Confirmed by there documentation.

So I run Sway and Hyprland (not convinced yet which one to use) and the second instance startups fast. So my workaround at the moment is to have a Ghostty instance in scratchpad on Sway and on workspace 11 in Hyprland. Then the rest of Ghostty instances startup fast.

It is not a elegant solution but one that works at the moment while testing Ghostty. But if the startup times don't improve then I will probably go back to Alacritty.

On Arch, ghostty version=1.0.1, Hyprland 0.46.2

https://ghostty.org/docs/help/gtk-single-instance

Ghostty is a GTK application. The GTK framework has unavoidable overhead when starting up, both in terms of how long it takes and how much memory it uses. Ghostty can't do anything about this.

GTK single instance mode avoids this overhead for subsequent instances of Ghostty. Launching a second instance of Ghostty will be extremely fast and use very little memory since it is just creating a new window in the existing instance.

[nikoksr]

@Proximus888, this reminds me of an issue I experienced before:

https://bbs.archlinux.org/viewtopic.php?id=285590

While Ghostty does work for me, it has notably longer startup times compared to other terminals. @FedeAbella's comment matches my experience:

Just got here cause I'm trying out ghostty on hyprland and found it a lot slower than kitty (my usual terminal). Same as above, it takes maybe a second or two to open, but by comparison that's incredibly slower than kitty.

Edit: @mitchellh After re-reading the original issue, I wonder if the OP might actually be experiencing the same GTK-related slowdown described in the Arch forum thread.

[Proximus888]

@nikoksr Don't think so, Firefox and other GTK apps startup pretty fast <1s. Only issue I have is with Ghostty +- 3s while other terminals apps open almost instantly.

But if I have already a open Ghostty instance open the following instances startup pretty fast <1s. That's why now as a workaround I keep a Ghostty instance open.