sleep inhibitor prevents the system from shutting down

[AngelSherry]

Describe

Because there is a delay in sleep-inhibitor's detection status, when I try to shut down after completing a compilation using sleep-inhibitor, it prevents the shutdown and causes the entire desktop environment to go black.

I have no choice but to switch to a TTY and log in to manually force a reboot using sudo reboot -f, because a normal reboot results in a message stating that it was interrupted by sleep-inhibitor.

sleep-inhibitor should not forcibly take control of reboot or poweroff events.

My sleep-inhibitor.conf

# Configuration file for sleep-inhibitor program. Copy this to
# /etc/sleep-inhibitor.conf and edit as you want.
#
# Normally the plugin dir (for provided plugins) is automatically
# determined (e.g. at either /usr/share/sleep-inhibitor/plugins or
# /usr/local/share/sleep-inhibitor/plugins) but you can define it
# explicitly here if you want, e.g. for custom config file for testing.
#
# Note period values in this file are specified in minutes by default.
# E.g. "2" is 2 minutes. However, you can append an "s", "m", or "h" to
# specify in seconds, minutes, or hours, e.g. "2s" is 2 seconds, "2m" is
# 2 minutes (i.e. same as "2"), or "2h" is 2 hours.
#
plugin_dir: /etc/sleep-inhibitor/
#
# Default global check period in minutes. Can be specified for each
# plugin, or if not specified will be the global default you define
# here, or is 5 mins if not specified at all.
#
# period: 5
#
# Default global check period, while ON/INHIBITING, in minutes. Can be
# specified for each plugin, or if not specified will be the global
# default you define here, or is "period" above if not specified at all.
# Will be limited to "period" value so can not be larger.
#
# period_on:
#
# Default global "what" value. Can be specified for each plugin, or if
# not specified will the global default you define here. Takes a
# colon-separated list of one or more operations to inhibit. See the
# description of the --what option in the man page for systemd-inhibit.
# Defaults to the default value of that systemd-inhibit option.
#
# what:
#
# Plugins are defined following. You can define as many plugins as you
# require. Custom plugins are specified with an absolute path to your
# own executable file. Standard plugins (i.e. those included in the
# distribution plugins/ dir) are specified with no path.
#
# Arguments are specified as below:
# path:   Must be specified. Can be an absolute path for custom
#         plugins, or relative to the program distribution plugins/
#         directory for standard plugins.
# args:   Optional. Provides arguments to the above script if required.
# period: Optional. Specifies period to check in minutes. Defaults to
#         global value, see above.
# period_on: Optional. Specifies period to check (while ON/INHIBITING)
#         in minutes. Defaults to above "period" value, then global value.
# name:   Optional. Descriptive name for logging. Defaults to basename of
#         path.
# what:   Optional. Takes a colon-separated list of one or more
#         operations to inhibit. Defaults to global value, see above.

# Comment/delete out or edit the following examples, or add your own.
plugins:

    # Inhibit sleep if any audio is playing
    # - path: is-alsa-playing
    #   name: Audio Playing

    # Inhibit sleep when Plex media server is serving content to users.
    # You need to specify your Plex token as the argument here. To
    # determine your plex token, see
    # https://support.plex.tv/articles/204059436-finding-an-authentication-token-x-plex-token/
    # To wake your PC if previously suspended, use any "wake on LAN" app
    # on your phone.
    # - path: plex-media-server
    #   name: Plex Media Server
    #   args: <your-plex-token>

    # Inhibit sleep when Jellyfin media server is serving content to users.
    # You need to specify your Plex token as the argument here. To
    # determine your plex token, see
    # https://support.plex.tv/articles/204059436-finding-an-authentication-token-x-plex-token/
    # To wake your PC if previously suspended, use any "wake on LAN" app
    # on your phone.
    # - path: jellyfin-server
    #   name: Jellyfin Media Server
    #   args: <your-jellyfin-token>

    # Inhibit sleep if a process is running. Here I
    # suppress suspend if my home backup script is running.
    - path: is-process-running
      name: video2x
      args: video2x

    - path: is-process-running
      name: makepkg
      args: makepkg

    - path: is-process-running
      name: paru
      args: paru

    - path: is-process-running
      name: yay
      args: yay

    - path: is-process-running
      name: pikaur
      args: pikaur

    - path: is-process-running
      name: duperemove
      args: duperemove

    # Inhibit sleep if 1 or more remote users are logged in via ssh
    # suppress suspend if my home backup script is running.
    - path: ssh-session-open

    # Inhibit sleep if apk (Alpine [Linux] Package Keeper) is running
    # - path: apk-running

    # Inhibit sleep if pacman (Arch [Linux] Package Keeper) is running
    - path: pacman-running

# vim:se sw=2 syn=yaml et ai:

Information

Operating System: Arch Linux
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.25.0
Qt Version: 6.11.0
Kernel Version: 6.18.22-1-cachyos-lts (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 9 5900HX with Radeon Graphics
Memory: 32 GiB of RAM (29.3 GiB usable)
Graphics Processor 1: AMD Radeon Graphics
Graphics Processor 2: NVIDIA GeForce RTX 3070 Laptop GPU
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ASUS TUF Gaming A15 FA506QR_FA506QR
System Version: 1.0

[bulletmark]

sleep-inhibitor does not forcibly take control of reboot or poweroff events. It is a simple program which merely sets uses the standard systemd-inhibit to tell your system that something is running which should inhibit shutdown. It also does not cause the entire desktop environment to go black, that must be something to do with your particular DE and/or environment.

You installed it so it is expected you read the instructions about what is does and how to use it. You should be setting the value of period_on to make sure it removes the inhibit quickly when a plugin is running. E.g. set period_on 5s either globally or per plugin, in your config file so that it removes the inhibit after 5 secs.

BTW, defining and running the is_program_running plugin 6 times is quite verbose and inefficient, just replace them all with:

- path: is-process-running
  name: Process Check
  args: video2x makepkg paru yay pikaur duperemove

[AngelSherry]

I noticed that in your sleep_inhibitor.py script, you have the lines:

    period = conf.get('period', '5m')
    period_on = conf.get('period_on', period)
    what = conf.get('what')

Consequently, I have now uncommented the what: line in /etc/sleep-inhibitor.conf and changed it to what: sleep:idle to see if that resolves the issue.

If that proves effective, perhaps you could modify that section of sleep-inhibitor.py to look like this:

    period = conf.get('period', '5m')
    period_on = conf.get('period_on', period)
    # If "what" is not specified in the configuration file, default to inhibiting only "sleep"' and "idle"
    what = conf.get('what', 'sleep:idle')

This way, the script would work correctly out of the box, without requiring users to manually adjust parameters such as period_on or what:.

[bulletmark]

What is the problem are you trying to fix?

[AngelSherry]

The problem is a race condition between the user initiating a shutdown and the script's polling interval, combined with systemd-inhibit's default behavior.

Here is the exact sequence that causes the system to soft-lock:

1. A watched process (like makepkg) finishes.
2. The user immediately clicks Shut Down in the Desktop Environment (like KDE Plasma).
3. The DE starts the shutdown sequence and kills the GUI components (the screen goes black, no UI is clickable).
4. systemd receives the poweroff request but sees that sleep-inhibitor still holds a lock. Because the default --what value in systemd-inhibit includes shutdown, systemd blocks the poweroff process.
5. Because period or period_on defaults to 5 minutes, sleep-inhibitor might not release this lock for several minutes.
6. The system is now stuck in a limbo state: the GUI is completely dead, but the machine refuses to power off.

While setting period_on: 5s mitigates this by reducing the freeze window to 5 seconds, it doesn't address the core logical issue: sleep-inhibitor is taking a shutdown lock by default when it doesn't need to.

Given the project is named sleep-inhibitor, users typically expect it to prevent idle suspensions during long background tasks, not to prevent a deliberate, manual shutdown command from the user.

By changing the code to default to what="sleep:idle", the script fulfills its primary purpose perfectly out of the box, completely eliminating the risk of this DE soft-lock scenario without requiring users to manually tweak timing variables just to safely turn off their computers.

[bulletmark]

So your complaint is that you don't like the default "what" choice this script defaults to. Why instead of quoting Python code etc, you didn't just say that?

This simple program is little more than a small wrapper around the systemd-inhibit utility. As such, if you don't specify a "what" condition you want to inhibit, then it just lets systemd-inhibit use it's default (see the man systemd-inhibit). I think that is sensible and what most users would want/expect. It is also clearly described in the sample template sleep-inhibitor.conf file and also refers the user to the aforementioned man page when describing the what value.

So if you don't like that default, then change it in your configuration! I think the systemd-inhibit default is the most appropriate and am not willing to change it sorry.

I may change the default period_on value as I can see that it would be more sensible as a lower value than period for most users (given so many don't read the documentation). I will think about that.

[AngelSherry]

This is not a complaint about personal preferences; it is a bug report regarding a critical failure in the system state caused by how the tool interacts with the Desktop Environment during a shutdown.

The core issue is that systemd-inhibit does not pause the shutdown—it completely aborts it.

Here is the technical reality of what happens with the current default behavior:

1. When a user clicks shutdown, the Desktop Environment (like KDE) immediately starts tearing down the session and kills the GUI. The screen goes black.
2. systemd then attempts to execute the poweroff sequence but is intercepted by sleep-inhibitor holding the default shutdown lock.
3. systemd aborts the shutdown sequence entirely and logs that it was interrupted.
4. Whether sleep-inhibitor releases the lock in 5 seconds or 5 minutes (via period_on) is completely irrelevant. The shutdown process has been permanently cancelled and will not automatically resume.
5. The system is now trapped in an unrecoverable, headless state. The GUI is dead, but the machine is still running. The only way out is for the user to manually switch to a TTY, log in, and execute sudo reboot -f.

This happens regardless of which plugin is active (process, SSH, samba, etc.).

If you believe strictly inheriting the upstream systemd-inhibit default is the right design choice for this wrapper, that is entirely your prerogative as the maintainer. I have already adjusted my local configuration to what: sleep:idle to avoid this.

However, you should be fully aware that for any user running a Desktop Environment, this default behavior fundamentally breaks the system's ability to shut down gracefully, turning what should be a background utility into something that forces hard reboots via TTY.

[bulletmark]

A user could just run standard systemd-inhibit command normally at the command line and cause that issue without anything to do with this program. I.e. you are pointing out that KDE does not work properly with that stock systemd command so perhaps you should raise a bug on either KDE and/or systemd? I use GNOME and it at least just refuses to shut down, although it unfortunately does not give an explicit popup/reason why. You have to run systemd-inhibit --list to see why. I also wish the major DE's would integrate better with systemd in this area but that is currently how it is.

In short, this is a simple wrapper around systemd-inhibit and so it uses it's defaults which I think is the best and most sensible approach. E.g. a user's backup script likely should not be interrupted by suspend or accidental shutdown.

[bulletmark]

PS: See https://bugs.kde.org/show_bug.cgi?id=469801