Timekpr fails to logout the users. I don't see any errors in /var/log/timekpr.log

Asked by Bartłomiej

`$ tail /var/log/timekpr.log`
```
2023-03-16 22:56:49.514266: get time for "cloufish", tltd 0, tlrow: 0, tspbal:
0, tspbt: 0, tidbt: 69
2023-03-16 22:56:49.514444: --- end working on users (ela: 0:00:00.003921) ---
2023-03-16 22:56:52.513703: --- start working on users ---
2023-03-16 22:56:52.517736: get time for "cloufish", tltd 0, tlrow: 0, tspbal:
0, tspbt: 0, tidbt: 72
2023-03-16 22:56:52.517845: --- end working on users (ela: 0:00:00.004151) ---
2023-03-16 22:56:55.514442: --- start working on users ---
2023-03-16 22:56:55.516836: get time for "cloufish", tltd 0, tlrow: 0, tspbal:
0, tspbt: 0, tidbt: 75
2023-03-16 22:56:55.516929: --- end working on users (ela: 0:00:00.002495) ---
2023-03-16 22:56:58.517623: --- start working on users ---
2023-03-16 22:56:58.521016: get time for "cloufish", tltd 0, tlrow: 0, tspbal:
0, tspbt: 0, tidbt: 78

```

Distro: Arch Linux
Installed via AUR

`$ echo $XDG_SESSION_TYPE`:
tty

^ does the above is the cause of this issue? I run simple windows manager on xorg and run it with startx.
Here's my .xinitrc:
```
if [ -f "${XDG_CONFIG_HOME:-$HOME/.config}/x11/xprofile" ]; then
 . "${XDG_CONFIG_HOME:-$HOME/.config}/x11/xprofile"
else
 . "$HOME/.xprofile"
fi

ssh-agent dwm
dbus-update-activation-environment --all
```

And xprofile:
```
autostart="mpd xcompmgr dunst unclutter pipewire"

for program in $autostart; do
 pidof -s "$program" || "$program" &
done >/dev/null 2>&1

# Ensure that xrdb has finished running before moving on to start the WM/DE.
[ -n "$xrdbpid" ] && wait "$xrdbpid"
```

If there's anything I can provide then please ask!!!
I really want to get timekpr setup :x

Question information

Language:
English Edit question
Status:
Solved
For:
Timekpr-nExT Edit question
Assignee:
No assignee Edit question
Solved by:
Bartłomiej
Solved:
Last query:
Last reply:
Revision history for this message
Eduards Bezverhijs (mjasnik) said :
#1

If you run your session using tty, this might be the culprit.

Try to remove tty from excluded session types and add it to the tracked session types in admin app.

If that does not really help, I’ll need full log files and config files too.

Revision history for this message
Bartłomiej (cloufisz) said :
#2

Hello,

I just want to confirm that BOTH removing from excluded AND adding to the tracked session solved the issue
I previously only added it to Tracked but not removed from excluded (And to be honest, I don't really see why not just assume by default that a session not in the tracked session is exluded by that logic)

Thank you so much!