Linux power inhibitor repeatedly prompts for Polkit authentication and can trigger PAM lockout

[jetersen]

Summary

On Linux, Jcode v0.67.1 can repeatedly open Polkit password prompts while a session is streaming. Dismissing or failing those prompts causes systemd-inhibit to exit, after which Jcode's 5-second reconciliation loop launches it again without a retry limit or backoff. On my system this repeated until PAM temporarily locked my account after three failures.

This occurred on a machine where automatic idle suspend is disabled on both AC power and battery. The machine had remained continuously awake for more than a week with no recorded suspend/resume events. Suspend is still technically available for explicit requests and lid-switch handling, so this is not a claim that systemd suspend is globally disabled.

Environment

• Jcode: v0.67.1
• Linux with systemd/logind and Polkit
• Automatic idle suspend disabled on both AC power and battery; systemd idle action set to ignore
• [power].prevent_sleep_while_streaming was at its default value of true
• org.freedesktop.login1.inhibit-block-sleep required authentication for the Jcode background process

Reproduction

1. Use a Linux setup where a background process requesting org.freedesktop.login1.inhibit-block-sleep requires Polkit authentication.

2. Leave the default setting enabled:

   [power]
   prevent_sleep_while_streaming = true

3. Start Jcode and run a turn so a session is actively streaming/processing.

4. Dismiss or fail the Polkit password prompt.

5. Observe that another prompt appears shortly afterward. Repeating this can trigger pam_faillock.

Observed behavior

Jcode launched:

systemd-inhibit --what=sleep:handle-lid-switch \
  --who=jcode \
  --why="Jcode is streaming or processing active work" \
  --mode=block sleep 150

Redacted journal excerpts:

polkitd: Operator ... FAILED to authenticate to gain authorization for action org.freedesktop.login1.inhibit-block-sleep ...
pam_faillock(polkit-1:auth): Consecutive login failures for user <redacted> account temporarily locked
polkitd: Operator ... FAILED to authenticate ... [systemd-inhibit --what=sleep:handle-lid-switch ...]

The implementation reconciles every 5 seconds. A successful spawn() is recorded as an acquired handle before Polkit authorization completes; when authorization fails and the child exits, the next reconciliation starts a fresh helper. There is no authorization-specific failure handling or backoff:

• server.rs: 5-second reconciliation loop
• power_inhibit.rs: respawn after an exited helper
• power_inhibit.rs: systemd-inhibit command

Expected behavior

A best-effort power inhibitor should not repeatedly request authentication or risk locking the user's account. If inhibition is not authorized, Jcode should fail noninteractively and either disable inhibition for the process lifetime or use a bounded backoff/retry policy.

Possible approaches include passing systemd-inhibit --no-ask-password and treating its nonzero exit as unavailable, or otherwise preventing repeated interactive authorization attempts.

It may also be useful to avoid acquiring an inhibitor when all automatic idle-suspend mechanisms are disabled, if that can be detected reliably. Explicit and lid-triggered suspend would remain separate considerations.

Workaround

This stops the behavior:

[power]
prevent_sleep_while_streaming = false

JCODE_DISABLE_POWER_INHIBIT=1 is also documented as a force-disable override.

Related issue

#452 fixed the TUI ignoring prevent_sleep_while_streaming = false. That setting works in v0.67.1; this report concerns repeated authentication attempts when the default-enabled inhibitor cannot be authorized.

[1jehuang]

Confirmed the reported retry loop in the Linux power inhibitor lifecycle. I opened #784 with a focused fix that makes Polkit authorization noninteractive and disables further attempts for the daemon lifetime after an unsuccessful helper exit.

Validation: formatting and whitespace checks passed, and all 6 focused power inhibitor tests passed.

--- — Jcode agent (automated triage), on behalf of @1jehuang