search

ActivityWatch / aw-qt

Tray icon that manages ActivityWatch processes, built with Qt.
Mozilla Public License 2.0
27 stars 29 forks source link

Doesn't shut down properly #49

Open johan-bjareholt opened 4 years ago

johan-bjareholt commented 4 years ago

We need to rewrite how the program shuts down its modules when it gets some termination signal, I can see many flaws as well as an obvious TODO in trayicon.py.

Realized after this report from the forums https://forum.activitywatch.net/t/activity-watch-does-not-end-with-session-xubuntu/393

xylix commented 4 years ago

Might be related, activitywatch also doesn't properly shut down at all when I click the "quit" from the trayicon on MacOS.

killall aw-qt works though, both from terminal started and the app version.

Kj-is-escape commented 3 years ago

This is still a problem

felixmde commented 2 years ago

I am on Arch Linux using Awesome WM v4.3. I run AW via the desktop file and xdg-autostart.

I wanted to report that I faced the issue where aw-watcher-afk and aw-watcher-window flood the terminal with messages after shutting down the window manager using AW v0.11.0.

If I build the latest development branch (as of today), I do no longer see the issue. Instead what happens is that aw-watcher-afk and aw-watcher-window die once aw-qt is killed by shutting down the window manager. aw-server keeps running and when restarting the window manager a warning pops up that aw-server is already running. Previously, all three (aw-watcher-afk, aw-watcher-window, aw-server) would keep running and there would be three error pop-ups when restarting the window manager.

I tried to find out what makes this difference and one thing that I noticed is that with v0.11.0 there are two processes for each each of aw-qt, aw-server, aw-watcher-window, aw-watcher-afk. It seems like they get started twice but then only one process is handled by the shutdown code.

Regarding the shutdown code itself, I don't actually see the obvious flaw in traycon.py. If I run aw-qt manually and send SIGTERM (that's what killall sends too on my machine) or SIGQUIT, in both cases everything shuts down properly. The only issue is SIGKILL because that implicitly kills the watchers, but not the server (which could be considered okay behavior).

TL;DR: I don't longer see the issue in the latest development build and I am not sure that the shutdown code was the issue to begin with.