Repository navigation
aw-qt-0^20240903 always fails to locate aw-server on first invocation after server boot. #113
Description
The Reproduction Method 1
-
#!/usr/bin/env sh aw-server && \ aw-qt
-
-
Restart
Its Consequence
2025-08-12 10:55:24 [WARNING]: Tried to stop module aw-server, but it wasn't running (aw_qt.manager:185) 2025-08-12 10:55:55 [INFO ]: Starting module aw-server (aw_qt.manager:148) [2025-08-12 10:55:55][INFO][aw_server]: Using DB at path "/home/RokeJulianLockhart/.local/share/activitywatch/aw-server-rust/sqlite.db" [2025-08-12 10:55:55][INFO][aw_server]: Using aw-webui assets at path None [2025-08-12 10:55:55][INFO][aw_server::endpoints]: Starting aw-server-rust at 127.0.0.1:5600 Error: Bind(Os { code: 98, kind: AddrInUse, message: "Address already in use" })
My Diagnosis
Could it be because the aw-server option comes disabled (that is, by default) in the System Tray icon's QMenu's “Modules” QAction?
My Environment
-
The Server And Client
-
#!/usr/bin/env sh rpm -qa *-aw*
-
python3-aw-core-0.5.17-3.fc42.noarch python3-aw-client-0.5.14-2.fc42.noarch nodejs-aw-webui-0^20250507.9259df7-2.fc42.noarch python3-aw-qt-0^20240903.43864b2-2.fc42.noarch
-
-
The OS And DE
Details
-
#!/usr/bin/env sh fastfetch -l none -
OS: Fedora Linux 42 (KDE Plasma Desktop Edition) x86_64 Host: Laptop 16 (AMD Ryzen 7040 Series) (A7) Kernel: Linux 6.15.9-201.fc42.x86_64 Uptime: 1 hour, 1 min Packages: 2926 (rpm), 23 (flatpak) Shell: bash 5.2.37 Display (BOE0BC9): 2560x1600 @ 165 Hz (as 1706x1066) in 16" [Built-in] DE: KDE Plasma 6.4.4 WM: KWin (Wayland) WM Theme: Breeze Theme: Breeze (Dark) [Qt], Breeze-Dark [GTK3/4] Icons: breeze-dark [Qt], breeze-dark [GTK3/4] Font: Monospace (10pt) [Qt], Monospace (10pt) [GTK3/4] Cursor: breeze (24px) Terminal: konsole 25.4.3 CPU: AMD Ryzen 7 7840HS (16) @ 5.14 GHz GPU: AMD Radeon 780M Graphics [Integrated] Memory: 11.11 GiB / 30.65 GiB (36%) Swap: 0 B / 8.00 GiB (0%) Disk (/): 190.47 GiB / 929.91 GiB (20%) - btrfs Local IP (wlp1s0): 192.168.1.219/24 Battery (FRANDBA): 87% [Charging, AC Connected] Locale: en_GB.UTF-8
-
Activity
addy-zero commentedon Oct 28, 2025
Similar error.
aw-server crashes almost everytime during startup (Linux Mint).
Contents of 'Show Details':
TimeToBuildBob commentedon Feb 27, 2026
This is expected behavior when you run
aw-servermanually beforeaw-qt. Here's what happens:aw-server && aw-qtstartsaw-serveras a standalone process (binds to port 5600)aw-qtlaunches, it tries to start its ownaw-servermodule — but port 5600 is already takenThe fix: Don't run
aw-serverseparately.aw-qtmanagesaw-serveras a subprocess — just runaw-qtalone:The "Modules" menu in the tray icon shows which modules aw-qt is managing. If
aw-servershows as disabled there, it means aw-qt detected that something is already listening on port 5600 and skipped launching its own instance.If you need to run
aw-serverstandalone (e.g., aw-server-rust while aw-qt is configured for the Python server), you should disable the server module in aw-qt's config (aw-qt.toml) to avoid the conflict.beedell-roke commentedon Feb 27, 2026
If I understand correctly, @TimeToBuildBob, is the problem is two-fold? Specifically:
aw-serverisn't being invoked by default by the Qt client, because something has taken the server's port, and the Qt client has not been designed to choose another port, if 5 000 is unavailable; and:If the user attempts to bypass this, by manually invoking
aw-server, which can automatically choose a different port when invoked outside of the Qt client, the Qt client does not identify the invoked server instance, albeit merely until it is reinvoked.TimeToBuildBob commentedon Feb 27, 2026
Mostly correct on point 1, but point 2 has a misconception worth clarifying:
Point 1 ✓: aw-qt always tries to start aw-server on port 5600. It doesn't have logic to detect a port conflict upfront — it just tries to bind and fails. There's no alternative-port fallback.
Point 2 — the standalone aw-server also uses port 5600 by default. It doesn't automatically choose a different port. Both the standalone invocation and aw-qt's managed instance compete for the same port.
The flow in your case:
aw-serverstarts → binds port 5600 ✓aw-qtstarts → tries to launch its own aw-server on 5600 → fails with "Address already in use"So the "Restart" essentially makes aw-qt re-probe the port without trying to manage a subprocess. It works, but the whole issue is avoided by just running
aw-qtdirectly — it starts aw-server for you.beedell-roke commentedon Feb 28, 2026
@TimeToBuildBob, that's a reasonable workaround, but aren't there reasons that the server would already be running without the client, or are they never separately invoked?
TimeToBuildBob commentedon Feb 28, 2026
Good question. There are a few scenarios where aw-server might already be running:
But for the normal desktop use case: no, you'd just run
aw-qtand it handles everything. The only real "bug" here is that aw-qt's error message on port conflict is confusing — it should detect an existing server and connect to it on first try, rather than requiring a manual "Restart" click.fix(manager): detect existing server on startup, avoid port conflict
TimeToBuildBob commentedon Mar 11, 2026
PR submitted: #123
Implements pre-startup detection of existing aw-server instances. When aw-server is already running (systemd, Docker, manual start), aw-qt now connects to it automatically instead of failing and requiring a manual Restart click.
fix(manager): detect existing server on startup, avoid port conflict
TimeToBuildBob commentedon Mar 16, 2026
This is addressed by #123 (currently open, pending review). The PR adds a pre-startup check that probes the server port before launching — if a server is already running (systemd, Docker, manual), it marks the module as 'external' and skips launching its own subprocess, avoiding the bind error entirely.
fix(manager): detect existing server on startup, avoid port conflict (#…