I am thinking of making a fun little background script that runs every few minutes (just often enough to trigger before a screen lock would occur) that will do a short challenge response against a server and if it succeeds block the lock event from occuring.
or even try a silent fido test if a stick is stil there and do the same.
so I would need a way to temporarily inhibit the lock screen effectlvely saying “I am still here”, I would not want to specifically disable or re-enable the lock screen as ideally the script should always fail in a way that the lock screen triggers normally.
basically the script would e.g. be in crontab or whatever to be triggered every e.g. 4 minutes (with the lock timer being at 5)
the would basically be run challenge(s), if successful, send the signal or whatever, and if it fails just do nothing
also if the computer is already locked the script should not be able to unlock the session
but as far as I can see this thing is basically running something and inhibit while that program is running.
key point is that I do not wanna run a “long term” inhibit, but just reset the timer and it restarts running normally either the script resets it again, or the timer does fire off and lock it.
also ideally I would prefer if the screen goes off normally
Yes, correct. Inhibition is bound to a process so it will be released even if it crashes.
A more complex program can start and stop inhibition more flexibly, e.g. when a video starts and stops playing but the program ending will always release it.
Base principle of the inhibition mechanism is that there needs to be one or more reasons to do so. Any program can announce (and holds) its reason for any duration, the mechanism will resume locking when all of them have been withdrawn.
It might depend on the implementation of whether it will reset its timeout handling when that happens or if it pauses its timers and resumes its timers.
My guess is the former but you would need to test that, e.g. by running systemd-inhibit sleep 1 in a loop and check if inhibit happens and/or how long it takes after the loop ends.
Alternatively you could try to make your detection of inhibition reason more compatible with how systemd-inhibit is intended to be used.
For example your use case of inhibiting while a fido stick is present could call systemd-inhibit is-fido-still-present.sh when the stick is inserted and the is-fido-still-present.sh keeps running until it no longer is.
I see, my key worry was if some weird thing happens, e.g. the process hanging without actually dying might be an issue which is why I thought maybe one could send something that just kicks the timer back and doesnt need to be active all the time so unless the thing is actively being checked it doesnt do anything.
also not sure from the parameters if i can only inhibit locking but keep the things like screen turning off alive, as I assume both are handled on the “idle” keyword.
I don’t remember the details but the mechanism might require an inhibiting process to reaffirm its reason regularily.
You could try if occasionally inhibiting does have that effect.
Yes, good question.
There might be other tools with different options but command line interfaces sometimes don’t expose all options of an API that other programming environments, e.g. Python, would have available