News and announcements
Finally working lock screen time detection
Written for Timekpr-nExT by Eduards Bezverhijs on 2020-04-12
First of all, not many bugs seems to be bugging Timekpr-nExT users, although there was one serious about time accounting, which is fixed. That's good :)
Now, there is a great feature that finally is implemented rather reliably!
TL;DR + high level summary
-------
When user locks the screen and inactive time accounting is not set, time will be interpreted as inactive and time spent will not be accounted for users on most DEs.
Beware, that for Gnome3 and all who implement their way of considering session inactive - it's inactive only when screen turns off after locking the screen, while KDE (for example) considers screen locked when it's locked and there is no need for screen to be turned off!
Either way, good times for users :)
-------
More detailed and technical description
-------
After one user in questions section on launchpad and another one IRL complained about time accounting when screen is locked, I tried to think of the solution. As I stated in previous announcements and on Timekpr-nExT description page, it's not exactly possible using server side methods, because about every DE in existence set session idle flags differently thus rendering reliable detection impossible.
This issue or feature was not on my priority list, no one complained / asked questions and because of that I just didn't think of alternative solution until couple of days ago.
The solution is plausible and must work in most of DEs, let me explain...
Every user session should have a screensaver component exposed to their own session level DBUS, but timekpr operates as root user and connects to session manager interfaces on system bus. Manager interfaces, normally, are not available and modifiable by normal users, so normal user can not interfere with them, thus information there is reliable and can not be "faked" easily.
Screen locking, however, is normal user's thing and can be accessed only by that user.
As a side note, it is possible to connect to user DBUS from root, but then whole timekpr has to switch over to user permissions with all the consequences, I've tried that and it was not good at all.
So, the next thing I could do, was to implement this in client and make it push updates to server, however client being a client, is susceptible to user modifications and result "faking", that had to be taken care of as well.
So, I added functionality to client, now it connects to screensaver module and waits for it to inform timekpr about activation or deactivation. When screensaver activates, timekpr client gets an event which it passes to server. However, server can not trust anyone to just say "Hey, I'm idle... I really am and will be for a long time :)", so it issues verification request to which clients has to reply. If client does not reply or replies incorrectly, timekpr counts this user as active.
To be sure that client is actually inactive, server issues verification requests periodically. Requests are not the same all the time so not exactly trivial to fake, this ensures more trust between server and actual client.
Technically this was finicky to implement, but it works, but please be aware that Gnome3 & friends have different behaviour than KDE, XFCE or (insert Your favourite DE here). For Gnome3 make sure that when screen is locked, it actually turns off for this feature to work. For KDE & XFCE, just lock the screen and done, screen does not have to be off.
I would like to stress, that timekpr is just an observer here, it can ask everyone and their cousin about the state of session, if they will reply that session is not idle or is not locked, it can not do much in that situation...
Please note that screensaver detection is a client responsibility, thus can be faked by clever program user can write, but if user can write a piece of code that actually connects to timekpr DBUS, understand it's logic / verification requests, etc. and can fake results based on client / server interaction, maybe this user should not have timekpr enforced on him in the first place :)
This is now beta, if all goes well, it will be released as stable, but after confirmation that it works from at least multiple users.
BR, Eduards
Timekpr-nExT update after release
Written for Timekpr-nExT by Eduards Bezverhijs on 2019-08-07
Some time has passed since release and it seems that Timekpr-nExT is doing somewhat ok :)
There were couple of bugs and enhancement requests.
Bugs are fixed, latest two were improvements for Gnome3 users who just don't see full application name in application launcher / dash and fix for Timekpr-nExT client to start in Deepin (and other non-major DE's) to see icon and notifications.
Enhancement requests are not yet being worked on because my only use case for son went away since we had a deal that when he finishes elementary school he's old enough to manage his computer time on his own, which currently is not exactly ideal, it's plausible, but daughter who is quite younger is more responsible therefore there's not yet a need to manage her computer time at all.
I have checked internet about how much people know about Timekpr-nExT and I'll say people don't know much at all . This means that either people just use the software silently or don't know that it exists or simply don't need it :)
There are no publications or guides yet, it seems that people are not much interested in this, however, I found that for some reason or other people want to see a release tarballs for source code and not git repos (except ArchLinux) so I created first release tarball. Hopefully that helps.
There are couple of things:
* unless You create a question or bug, I simply DO NOT KNOW that something is not working or there is a need for smth (like the need for source tarballs)
* please share a word about Timekpr-nExT for people may need this
Happy timekpring :)
Timekpr-NEXT is released as stable
Written for Timekpr-nExT by Eduards Bezverhijs on 2019-06-06
Couple of months have passed after I released the beta version. Since then no bugs have been found, so I'm quietly releasing stable version.
Nothing has changed since the beta, except I added prefix to administration app launchers for unfortunate Gnome3 users who get launcher names truncated and can't distinguish between normal mode admin app and super user mode.
I may or may not start working on enhancements soon, let's see how adoption progresses.
Timekpr-NEXT is here
Written for Timekpr-nExT by Eduards Bezverhijs on 2019-04-08
Timekpr-nExT is here. It was a long road for me to get to this point. In this announcement I’ll explain a little how Timekpr-nExT works, what it does and what it does not.
Announcement is somewhat technical, the TL;DR is start it up and use, maybe read how hour intervals work but that’s it :)
-------
How Timekpr-nExT works.
Basically Timekpr-nExT is using login1 (systemd’s login manager) to get information on logged in users and their sessions via D-BUS, in fact everything Timekpr-nExT does to user or it’s sessions is going through login1.
Timekpr-nExT daemon is running in the background and constantly monitoring user sessions, the interval at which it does its thing, is 3 seconds by default. It’s not recommended to change the query interval to less than 3 secs, 3 secs is about to be right.
The time is accounted as a difference between previous check time and the time in moment of current check, it’s accounted in memory and is saved on disk every 30 secs by default, it’s possible to configure the save at different intervals, but default should suffice vast majority of users.
Timekpr-nExT lists all the users that are logged in, then for every user Timekpr-nExT lists all the sessions. If someone wonders what’s the difference, well, user might have more than one session, he can be logged in via graphical interface as well as TTY.
Timekpr-nExT has configuration for users which will be not tracked at all, that means Timekpr-nExT won’t process anything about them. This option was meant to list all users which are not exactly normal users - login managers and the like. Please do not specify Your normal user here, Timekpr-nExT client application won’t receive anything for this user, so it will stay in “unconnected” state forever. If one wants to give user unrestricted time, please don’t limit the user in any way.
Sessions have their types, for instance x11 / wayland / tty / etc., Timekpr-nExT have configuration to specify which of them are actually tracked. By default all graphical sessions are tracked, which means that if user is logged in using GUI, time spent is accounted. TTY sessions are not tracked by default, which means that if user is logged in through console, Timekpr-nExT will not account time spent there. It’s possible to change session types to be tracked and excluded, but please be careful, one has to know exact sessions types to be entered.
After sessions are gathered, Timekpr-nExT will check whether user has allowance to be logged in and how much time he has left. Every option and limit influences how much time user has left, they are all taken into account at the same time.
The day configuration is rather simple, one has to check whether user can use the computer in particular day and what is the time limit for this day.
Hour intervals determine the times user is allowed to log in and use the computer. There can be more than one interval, say from 15:00 – 17:30 and 19:30 – 22:15. Since Timekpr-nExT is not about micromanaging the user, so there can be just one interval that starts or ends in the same hour. Previous examples shows how one can configure the user, this one will show not one can NOT configure it: one can not enter intervals 15:00 – 17:30 and 17:45 – 22:15. This is a design decision. Lets hope it’s fine for most users, if not, please register enhancement request and let’s see how many of You need to micromanage the user :)
One little thing – time is in 24h intervals, AM/PM was not even planned, I hope everyone can live with this :)
Hour intervals basically are meant to limit user not to use computer when they need to be at school or when they have to do homework or something else.
Please note that there is a possibility to allow user to use computer across midnight without being kicked out. The end of the interval should be 24th hour and start interval for the next day must start at 0. I use this on Fridays and Saturdays because next day is not “working” day for my user.
Here’s the example of Friday / Saturday for my user: Friday 13:00 – 24:00, Saturday: 00:00 – 1:00, 13:00 – 24:00 (sometimes my user plays with friends after midnight, however this might not suit every parent).
There are week and month limit as well, they are meant to limit user how much time can be spent per week or month. Combining this with hour intervals one can configure rather flexible time for its users, specify max per day, if needed – it’s absolutely optional, then hour intervals and week or month limit and let user decide how they want to spend the time during the week or month.
-------
When time ends or user is not allowed to log in at particular time of the day, Timekpr-nExT will give a final warning to the user 15 seconds before the forced logout, it will count time from 10 – 0 in real-time and after that user sessions are terminated.
Timekpr-nExT is not using Linux PAM or integration with login managers via config files as it was the case with timekpr and timekpr-revived. This solves frustration about locked accounts and wrong error messages from login managers when account is locked.
Timekpr-nExT changes icon color depending on hard-coded configuration, when there is plenty of time the icon is green, when there is less than half an hour, icon is yellow and when there is not much time left, icon is red. The same applies to the icon of notification, they depend on how much time is left to the user.
Notifications show very precise information about how much time is left, information comes from the Timekpr-nExT server where it’s accounted every 3 seconds.
I tried to program Timekpr-nExT as much user friendly as possible, so there are more warnings and error messages, if they happen. Icon in the systems notification area shows as much as possible for certain DE, for example, Unity shows all the info, KDE5 shows just the icon, it has time left in the tooltip and if You happen to use Gnome Shell, please install “TopIcons” or similar extension to see the icon, if You don’t do this, only notifications will be shown.
-------
Translations from BETA testers are coming in, there will be a small additional releases with new translations.
So please use it, if one finds a bug, please register it, if one finds a useful feature to be implemented, please register the enhancement request, I’ll try to answer it promptly as my time allows me.
-------
Updated .
Retirement of timekpr-revived, Timekpr-nExT is coming very soon...
Written for Timekpr-nExT by Eduards Bezverhijs on 2019-04-02
Timekpr-nExT development (at least initial set of features) is finally finished and timekpr-revived will not get any updates or bug fixes.
It was a long and bumpy road for me to get Timekpr to the state it's in now, it was quite time consuming. I started it at about in the middle of last year, now it seems to be working just fine :)
This announcement will be a little about development and stuff and while beta testers are finding last minute bugs, I'll post another announcement with detailed description of features of Timekpr-nExT.
-------
If You care about this project, want to contribute a little or just want to help me, soon repository will be public and You could help adding features / testing / translating, or if You don't do that daily / don't have time, there's an option to help me with PayPal: https:/
-------
Let's start with why I even started this. The thing was that timekpr-revived has quite some shortcomings, exactly as every software does :) It was good for years it existed, but dealing with it and explaining the child all little annoyances and/or strange behavior gave me a little boost to start a better version of something similar.
I had a plans to extend that to a little more than it currently is, but due to lack of interest from anyone, I didn't do that. You can read my announcements about that in announcement section of timekpr-revived.
-------
So the main shortcomings of old timekpr-revived.
One of the thing that gave indeterministic behavior was that timekpr was a “little” desynchronized between daemon and client application, they both read configuration and control files in their own time interval and therefore a user / child was not exactly sure when the time ends. This was influenced with the rate polling interval in timekpr, but in the end for the user, there was a message "session will be ended in about 2 minutes", which was pretty much true, it could end after 15 secs or 1 minute and 37 secs. It was, in fact, a distraction for my user, which would like to see precise time when session ends.
Another thing was that I could not add more than one time interval per day. One might have it's own reasons why that is a good idea, but mine was that in case my user's day sometimes starts at 10:00, so then he could wake up and play a little say from 7:30 to 9:30 and after school + after he has done his homework, he could start playing again from 18:00 - 22:15.
Another thing was that old timekpr used PAM heavily, which is not a bad thing by itself, but that gave users (my user as well) a bit of headache because when account was locked, it just showed "incorrect username or password" error, but everyone expected "this account is locked" which is not exactly how account lock works in linux. So people got frustrated, my user too. There were a config file updates to alter display manager config file, PAM config files etc. which is invasive, but served its purpose.
There were a lack of features, like user could not work past midnight w/o being kicked out, no sleep support, no inactive session time accounting, no time or month allowance, no precise of time accounting etc.
-------
The improvement over timekpr-revived is called Timekpr-nExT.
Before I even started, I laid out a plan to eliminate all of the main shortcomings of older version and started to test how to implement what I had planned.
There were some interesting things, like when I just tested whether features will work, on Ubuntu 14.04 everything worked fine, but more at more completed stage when development went further, it just segfaulted for no apparent reason. So, since 14.04 was going to be EOLed soon, I just dropped idea of supporting it.
At start I wanted to support consolekit and login1 (systemd). After looking around, I decided to support just login1, most of the distros use systemd nowadays, so supporting ck does not make much sense. It should rather easy to support it, but currently implementation files are just empty.
Timekpr uses login1 (systemd) for manager for all interactions, for user list, session list, etc. One of those things are session termination, Timekpr-nExT is asking login1 (systemd) manager to terminate user session, but sometimes on some distros with some login managers it results in black screen which actually means that TTY is switched away from one which drives the graphical display. Graphical display is on TTY7 (ctrl+alt+f7) for older installations like 16.04 and TTY1 for newer ones. Maybe this has smth to do with console not-switching. In case it happens, one can return to correct one by pressing ctrl+alt+fx where x is TTY where login manager is on. I hope users won't be heavily affected by this.
Another interesting thing was how to determine whether session is idle. There are two things which I found I could use to determine whether session is idle: IdleHint and State.
When it works properly (16.04 + Unity and most of Gnome3 on any distro), State shows whether session is active, that means session is focused, for example desktop or console is shown, when one switches away, session state changes to online, which means it’s active, but not focused. IdleHint is means whether session is idle, eg. no-one is doing nothing in the session which basically means it’s locked.
For some reason KDE5 (for example) never set IdleHint to 1, thus session is not considered idle at any time. I even tried to force monitor off via xset, it didn’t work. Sorry KDE5 and other affected users. Maybe it’s time to file a bug :)
Interestingly, sometimes, even in 16.04, I have performance problems getting D-BUS objects, they are stuck for some 10-20 minutes for some reason I don’t know. Sometimes it happens, sometimes not, but calls eventually succeed. I’m trying to cache all objects which are somewhat permanent over the user sessions, so this should not be a major issue. I haven’t seen this behavior in 18.04 or later, though.
There were strange things with Glade as well.
I developed everything on 16.04 and it works flawlessly on it, 18.04 + Gnome3 works as well, including inactive session determination.
Beta testers on 18.04 Gnome3 + ArchLinux on KDE5 and Gnome3 says it’s working fine.
Anyhow, this was really quite a lot to do and I don’t plan to write more on how development went with all little strange thingies which differ from one installation to other, from one DE to other, etc.
-------
I'll address feature descriptions in next announcement, which will happen in about the time Timekpr-nExT is released which will happen pretty soon.
Updated .
