Policy "1" means "InterruptSession" which means suspending the system.

You might want to use "4" (which is change screen settings, which includes locking the screen) instead, or a combination of both (5). Generally this DBus interface isn't supposed to be used outside of Solid/KDE.

The label in battery monitor is misleading. PowerDevil functions as designed. It also doesn't post a logind inhibiton, it handles everything itself, so you won't see anything meaningful in systemd inhibit.

Ah, wait, so your " systemd-inhibit --who="test sleep" --what="sleep" --why="testing sleep without screen lock" sleep infinity" call isn't working. Sorry, I was too focussed on the Python example. Re-opening.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/121

Right - I was trying to make the point that the python code wasn't doing *quite* what I expected, either.

Basis for this issue...

I often have to ssh into remote systems while on battery power, but might have to be talking to a colleague (I work in higher ed).
I have, in my ~/.ssh/config:

LocalCommand ~/scripts/ssh_prevent_linux_idle_sleep.sh

Which looks like this:

#!/bin/sh
# Prevent a Linux box from sleeping while an SSH session is live.
#
# This is intended to be run using the LocalCommand function of ssh.
#
# It is recommended that this command only be used for hosts
# from which you do not desire to be disconnected, in the interest
# of power savings.

SSH_PID=$PPID
SSH_STARTTIME="$(ps -p $PPID -o lstart | grep -v '^.*STARTED')"

# Start a background child process that:
# 1) Starts "sleep infinity" in the background under systemd-inhibit
# 2) Monitors for the exit of the ssh parent process
# 3) Kills the "sleep" it started upon ssh parent exit
#
# We avoid a race condition that might prevent the systemd-inhibit process
# from being killed by starting it within the child.
(
systemd-inhibit --who="ssh" --what="sleep" --why="connected to remote host" sleep infinity &
INHIBITOR_PID=$!
while true
do
    checkstarttime="$(ps -p $SSH_PID -o lstart | grep -v '^.*STARTED')"
    rc=$?
    if [ ! \( $rc -eq 0 -a "$checkstarttime" = "$SSH_STARTTIME" \) ]; then
        kill $INHIBITOR_PID
        exit 0
    fi
    sleep 15
done
) &

In that case - and in the version of KDE present in KUbuntu 20.04 - what I want is for the system to *not* suspend, but be able to auto-lock (and, preferably, dim +/- turn off the screen, after the appropriate duration).

In the version of KDE in KUbuntu 22.04, the above script keeps the machine from suspending - and from auto-locking, and from dimming or powering off the screen, if I'm ssh'd into a host to which that LocalCommand applies.

Git commit 9aee819f3d1b234892700ccbddfa1f5bd6f10e9f by Kai Uwe Broulik.
Committed on 25/01/2023 at 12:38.
Pushed by broulik into branch 'master'.

Only inhibit screen locker on "ChangeScreenSettings"

This is the policy for e.g. dimming and turning off the screen,
i.e. "user can't see stuff anymore" which includes locking the screen.

"InterruptSession" is for suspend where the computer will not
continue its current tasks. The screen can still lock when I am
copying files or burning a CD.

M  +1    -1    powermanagement_inhibition.cpp

https://invent.kde.org/plasma/kscreenlocker/commit/9aee819f3d1b234892700ccbddfa1f5bd6f10e9f

Git commit cb4844aa8c906665feec027dccc21052d1689883 by Nate Graham, on behalf of Kai Uwe Broulik.
Committed on 25/01/2023 at 14:33.
Pushed by ngraham into branch 'cherry-pick-9aee819f'.

Only inhibit screen locker on "ChangeScreenSettings"

This is the policy for e.g. dimming and turning off the screen,
i.e. "user can't see stuff anymore" which includes locking the screen.

"InterruptSession" is for suspend where the computer will not
continue its current tasks. The screen can still lock when I am
copying files or burning a CD.


(cherry picked from commit 9aee819f3d1b234892700ccbddfa1f5bd6f10e9f)

M  +1    -1    powermanagement_inhibition.cpp

https://invent.kde.org/plasma/kscreenlocker/commit/cb4844aa8c906665feec027dccc21052d1689883

*** Bug 465859 has been marked as a duplicate of this bug. ***