Files
omarchycn/bin
David Heinemeier HanssonandClaude Opus 5 6e07fd0e82 Supervise fcitx5 so XCompose sequences can't silently die
fcitx5 is what turns the CapsLock compose sequences in ~/.XCompose into
text for Wayland clients -- CapsLock m s for an emoji, CapsLock space n
for your name. It was launched fire-and-forget from Hyprland's autostart
via uwsm-app, so nothing supervised it, nothing restarted it, and it
logged nowhere. When it went away, every compose sequence stopped
working for the rest of the session with no visible symptom beyond
"emoji input is busted", and no record of why.

That is not hypothetical: it was found dead on a running machine with no
coredump, no OOM kill, and nothing in the journal to explain it.

Move it to a systemd user service:

- Restart=always, not on-failure. fcitx5 exits 0 when it finds another
  instance already owning org.fcitx.Fcitx5, and a clean exit still
  leaves the user with no input method.
- After=/PartOf=graphical-session.target. It needs WAYLAND_DISPLAY and
  DISPLAY, which uwsm imports into the user manager before reaching the
  target, and its wayland connection dies with the compositor.
- ConditionEnvironment=WAYLAND_DISPLAY. After= is ordering only and does
  not stop the unit from being started while the target is inactive. An
  update over SSH has a live user manager (pam_systemd) and no graphical
  session, and a fcitx5 started there comes up blind -- then stays
  active, so the later target activation won't pull in a working one,
  because Wants= does not restart what is already running. Skipping the
  start leaves the unit enabled and healthy for the next graphical login.

The migration hands over inside a live session only: it enables without
--now, and only when graphical-session.target is active does it drop the
autostart-launched process and start the unit. Because that kills a
fcitx5 that was working a moment ago, a failed start is reported instead
of leaving the session mute with the migration marked complete.

omarchy-restart-xcompose now drives the unit. It still clears any fcitx5
running outside it first: that process owns the bus name, so the unit's
instance would exit on arrival and the stale one would keep serving the
old table -- a restart that reports success and changes nothing.

Side benefit: fcitx5 now logs to the journal under its own unit, so the
next disappearance leaves a record.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-27 09:49:15 -07:00
..
2026-05-21 15:45:36 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-21 19:30:30 +02:00
2026-05-01 17:40:22 +02:00
2026-05-06 12:58:55 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-21 19:30:30 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-25 20:28:39 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-17 21:30:58 +02:00
2026-05-01 17:40:22 +02:00
2026-05-21 19:30:30 +02:00
2026-05-25 18:19:06 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-23 04:32:20 -04:00
2026-05-20 14:09:09 +02:00
2026-05-20 14:12:06 +02:00
2026-05-19 20:54:20 +02:00
2026-05-19 20:54:20 +02:00
2026-07-25 13:39:42 -07:00
2026-05-19 20:54:20 +02:00
2026-05-14 12:02:53 +02:00
2026-05-14 12:02:53 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-06-04 18:37:32 -04:00
2026-05-01 17:40:22 +02:00
2026-05-04 11:18:25 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-05 14:22:03 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-05-01 17:40:22 +02:00
2026-06-04 11:14:04 +02:00
2026-06-04 11:14:04 +02:00
2026-05-01 17:40:22 +02:00
2026-06-04 18:37:32 -04:00
2026-06-28 20:46:23 -04:00
2026-05-08 20:48:36 +02:00
2026-05-01 17:40:22 +02:00
2026-06-04 18:38:25 -04:00
2026-05-01 17:40:22 +02:00