systemd 262 refuses to load Ghostty if it thinks we don't have a reload signal handler #14398

I've reproduced this consistently (not just ~1-in-9, on Arch. My current software: systemd 262, ghostty 1.3.1-2 via GNOME Shell + dash-to-panel extension click activation). I did not have this issue until this morning, updating to systemd 262 seems to have make it appear/make it worse.

Journal shows exactly why the launch silently fails:

Activating via systemd: service name='com.mitchellh.ghostty' unit='app-com.mitchellh.ghostty.service' ...
Starting Ghostty...
...
Main process <PID> lacks handler for reload signal USR2, refusing service startup.
app-com.mitchellh.ghostty.service: Failed with result 'protocol'.
Failed to start Ghostty.

Root cause: the shipped unit (dist/linux/systemd.service.in) uses Type=notify-reload + ReloadSignal=SIGUSR2. When the app is D-Bus-reactivated while the previous instance is still tearing down (e.g. last window just closed but process hasn't exited/isn't in a state to handle SIGUSR2 yet), systemd treats the reactivation as a reload instead of a fresh start, sends SIGUSR2, gets no handler response in time, and marks the unit failed - all silent from the GUI side (just a stuck busy cursor, no visible error).

Local workaround that reliably fixes it: drop Type=notify-reload/ReloadSignal=SIGUSR2 and use Type=simple instead:

[Service]
Type=simple
BusName=com.mitchellh.ghostty
ExecStart=/usr/bin/ghostty --gtk-single-instance=true --initial-window=false

No more failures across repeated open/close cycles since applying this. Only downside: systemctl --user reload for config reload no longer works via that signal path - haven't seen any other regression.

I have just hacked that directly in my systemd unit file, if and when this gets fixed upstream, pacman will just overwrite my change.

Originally posted by @cedricroijakkers in #11724 (comment)