Skip to content

Conversation

@trefzer
Copy link
Contributor

@trefzer trefzer commented Dec 5, 2025

The current provider uses two steps in the self.instances routine:

  1. Fetch all users currently logged in with the command loginctl list-users. Result is a list of all users with an open session (so this includes user which are lingering, users that are logged in etc.).
  2. For each found user the command loginctl show-user is executed to get the current state of the 'Linger' setting.

The second command also fails for users not logged in. Since the first command only lists logged in users, the falure is a quite seldom event (also described in #302 ).

A user with disabled linger is 'usally' (at least im not logged in on all machines running puppet ;)) not logged in, so it does not apear on the first command. Therefore it's linger status is not checked. This results in running loginctl to disable the setting on each puppet run (described in #301 ).

The approach I took in this MR is to get the Linger status in a single step and handle the failure in case the user is not logged in. If the user is logged in, we an use the Linger state to decide if lingering is activated or not. In the case the user is not logged in, it's for shure not lingering (since these are listed). So setting the is value to disabled should be correct.

Fixes: #302
Fixes: #301

@trefzer trefzer added the bug Something isn't working label Dec 5, 2025
@trefzer trefzer force-pushed the dev_fix_loginctl branch 2 times, most recently from d022465 to c98bb57 Compare December 5, 2025 20:32
@kenyon kenyon changed the title rewrite loginctl_user provider rewrite loginctl_user provider Dec 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Race condition within loginctl_user type loginctl disable-linger runs even when disabled

2 participants