Skip to content

fix: use delay mode and release power inhibitor on shutdown - #296

Closed
nvandamme wants to merge 1 commit into
Zarestia-Dev:masterfrom
nvandamme:fix/power-inhibitor-shutdown-handling
Closed

nvandamme wants to merge 1 commit into
Zarestia-Dev:masterfrom
nvandamme:fix/power-inhibitor-shutdown-handling

Conversation

@nvandamme

@nvandamme nvandamme commented Sep 12, 2026

Copy link
Copy Markdown
Contributor

Problem

On Linux, while any mount/job is active, RClone Manager acquires a logind
inhibitor lock with MODE=block. This causes two issues:

  1. systemd-logind refuses ManagerReboot/Shutdown entirely — on KDE Plasma,
    clicking "Restart" silently degrades into a black screen, waiting indefinitely instead of rebooting.
    The reboot transaction never starts.
  2. The PrepareForShutdown=true signal handler only logged a warning and never
    released the lock, so the lock survived until process exit even during shutdown.

Fix

  • Change the inhibitor mode from "block" to "delay": logind proceeds with
    the reboot after its grace period instead of refusing it outright. A user app
    cannot truly block power-off anyway (power button, Ctrl+Alt+Del, remote admin).
  • On PrepareForShutdown=true, actually call state.release() so the lock is
    released as soon as the OS begins shutting down — mirroring what already happens
    when all mounts are unmounted.

Verification

Tested on CachyOS (systemd 261, Plasma 6): with kDrive mounted and the patched
binary running, ListInhibitors now shows mode "delay", and KDE Restart performs
a real reboot instead of logging out.

- Change logind inhibitor lock from 'block' to 'delay': a block-mode
  lock made systemd-logind refuse ManagerReboot/Shutdown entirely, so
  KDE restart with an active mount silently degraded into a session
  logout instead of rebooting. Delay mode lets the OS proceed while
  still giving the app a grace period.
- Release the inhibitor on PrepareForShutdown=true: the signal handler
  previously only logged a warning and never released the lock, so the
  lock survived until process exit even when the OS was shutting down.
@nvandamme
nvandamme force-pushed the fix/power-inhibitor-shutdown-handling branch from 5091556 to 81b0cd0 Compare September 13, 2026 10:03
@Hakanbaban53

Copy link
Copy Markdown
Collaborator

Hi @nvandamme,

Thank you for opening this PR and highlighting the shutdown hang on KDE Plasma / systemd!

We looked deeply into this behavior across different desktop environments and inhibitor modes:

  1. The limitation with mode = "delay" on sleep:
    Systemd's delay inhibitor mode enforces a strict global timeout (typically 5 seconds). If sleep is set to delay, systemd only delays suspension for 5 seconds before forcing the system to sleep anyway — which interrupts long-running file transfers and syncs.
  2. The issue with mode = "block" on sleep:
    Setting sleep with block requires Polkit privileges (org.freedesktop.login1.inhibit-block-sleep), which triggers root password prompts when a user manually clicks "Sleep" or locks the screen, and prevents sleep when closing a laptop lid.

Solution Implemented

To solve both the shutdown hang and the sleep handling cleanly, we implemented a comprehensive fix:

  1. Switched to what = "idle", mode = "block":
    • Universal and unprivileged (no Polkit password prompts).
    • Prevents the OS from automatically going to sleep while active syncs, mounts, or jobs are running.
    • Allows passwordless manual sleep, screen locking, and hardware laptop lid-close sleep without interference.
  2. Integrated with PrepareForShutdown(true) on D-Bus:
    • When an OS shutdown or reboot is initiated, Rclone Manager receives the logind signal, triggers our graceful shutdown sequence (handle_shutdown to unmount FUSE remotes and terminate jobs), and immediately releases the inhibitor lock. This eliminates any black-screen hangs or delayed power-offs.

Because this required reworking the inhibitor target and adding the D-Bus signal listener, we have implemented this fix directly in the codebase (targeted for the upcoming release).

Closing this in favor of the integrated solution. Thank you again for your valuable contribution and for helping us diagnose this!

Fixes in this commit:
e510205

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants