New dialog on KDE "Authentication is required to suspend this system"

brachiosnorus · 2024-07-16 05:06:09

Recently I've started seeing a dialog when I resume my computer from suspend. It doesn't show up every time that I resume and I haven't observed any patter as to when it appears and when it doesn't.

I'm using latest Plasma and the dialog says: "authentication is required to suspend this system" with a prompt to enter my password. The details state:

Action: Suspend the system
ID: org.freedesktop.login1.suspend
Vendor: The Systemd project

My user is part of the following groups:

sys adm wheel

Suspend works without providing a password. If I do provide it (after resuming), I can see the following in journalctl:

Operator of unix-session:2 successfully authenticated as unix-user:xyz to gain TEMPORARY authorization for action org.freedesktop.login1.suspend for system-bus-name::1.39 [/usr/lib/org_kde_powerdevil]

How can I get rid of this dialog?

Last edited by brachiosnorus (2024-07-16 05:13:13)

V1del · 2024-07-16 08:27:07

A proper logind session should normally handle this. How are you login into the system/starting KDE?

loginctl session-status

since you seem to be able to suspend correctly, probably a quirk of the user session freezing introduced in systemd 256. You could disable that by creating a override for the systemd services involved in suspension, see: https://bbs.archlinux.org/viewtopic.php … 7#p2181817 -- and the last reply for the other places to add it

brachiosnorus · 2024-07-16 17:41:05

Thanks for the reply.

I'm just logging in via sddm. Here's the output of the command:

  Since: Mon 2024-07-15 20:21:37 CEST; 3h 46min ago
  State: active
 Leader: 1122 (sddm-helper)
   Seat: seat0; vc1
    TTY: tty1
 Remote: no
Service: sddm
   Type: wayland
  Class: user
Desktop: KDE
   Idle: no
   Unit: session-2.scope
         ├─1122 /usr/lib/sddm/sddm-helper --socket /tmp/sddm-auth-... --id 1 --start "/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland" --user xyz
         ├─1144 /usr/bin/kwalletd6 --pam-login 12 13
         └─1145 /usr/bin/startplasma-wayland

Jul 15 20:21:37 systemd[1]: Started Session 2 of User xyz.
Jul 15 20:21:37 sddm-helper[1143]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
Jul 15 20:21:37 sddm-helper[1145]: Jumping to VT 1
Jul 15 20:21:37 sddm-helper[1145]: VT mode didn't need to be fixed
Jul 16 18:15:29 kwalletd6[1144]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash

seth · 2024-07-16 20:57:28

V1del wrote:

session freezing introduced in systemd 256. You could disable that by creating a override for the systemd services involved in suspension

brachiosnorus · 2024-07-20 04:39:32

V1del, because this doesn't happen every time, it took a couple of days of observation to see that it is still happening despite having added the override.conf files and reloading the daemon.

seth · 2024-07-20 06:20:53

How exactly do you suspend the system?
Some KDE button, some shortcut (to what action) or eg. the lid?

Please post your complete system journal for a boot that shows the dialog after the resume, eg.

sudo journalctl -b | curl -F 'file=@-' 0x0.st

for the current one

brachiosnorus · 2024-07-21 05:48:59

Please see log: http://0x0.st/Xp-4.txt. Dialog appeared on latest resume.

I suspend the system either by closing the lid or using the KDE "sleep" option.

Last edited by brachiosnorus (2024-07-21 05:50:30)

seth · 2024-07-21 07:31:24

Jul 21 07:26:02 myhost systemd[1]: Stopped target Sleep.
…
Jul 21 07:26:07 myhost unix_chkpwd[38664]: password check failed for user (myuser)
Jul 21 07:26:07 myhost kscreenlocker_greet[36090]: pam_unix(kde:auth): authentication failure; logname=myuser uid=1000 euid=1000 tty= ruser= rhost=  user=myuser
Jul 21 07:26:07 myhost kdeconnectd[1819]: 2024-07-21T07:26:07 default: new capabilities for  "Pixel 6"
Jul 21 07:26:08 myhost kdeconnectd[1819]: 2024-07-21T07:26:08 kdeconnect.plugin.clipboard: Ignoring clipboard without timestamp
Jul 21 07:26:08 myhost kdeconnectd[1819]: 2024-07-21T07:26:08 kdeconnect.plugin.contacts: handleResponseVCards: Unable to open "/home/myuser/.local/share/kpeoplevcard/kdeconnect-46710e9fa0d1c741/3789r900-2C32443C2A423A4446403A54324C4E5244445A504C3A3646442A382A4C2A445A.3789r971-2C32443C2A423A4446403A54324C4E5244445A504C3A3646442A382A4C2A445A.2412ec8a5c240-6201-4e5a-8385-f74938b121c3..vcf.2399r1700-2C32443C2A423A4446403A54324C4E5244445A504C3A3646442A382A4C2A445A.2399r1713-2C32443C2A423A4446403A54324C4E5244445A504C3A3646442A382A4C2A445A.vcf"
Jul 21 07:26:09 myhost NetworkManager[1132]: <info>  [1721539569.2170] dhcp6 (wlan0): activation: beginning transaction (timeout in 45 seconds)
Jul 21 07:26:09 myhost NetworkManager[1132]: <info>  [1721539569.2174] policy: set 'mywifi' (wlan0) as default for IPv6 routing and DNS
Jul 21 07:26:09 myhost NetworkManager[1132]: <info>  [1721539569.3206] dhcp6 (wlan0): state changed new lease
Jul 21 07:26:13 myhost unix_chkpwd[38721]: password check failed for user (myuser)
…
Jul 21 07:26:29 myhost sudo[38857]: pam_systemd_home(sudo:auth): New sd-bus connection (system-bus-pam-systemd-home-38857) opened.
Jul 21 07:26:30 myhost sudo[38857]:      myuser : TTY=pts/1 ; PWD=/home/myuser/Downloads ; USER=root ; COMMAND=/usr/bin/su -
Jul 21 07:26:30 myhost sudo[38857]: pam_unix(sudo:session): session opened for user root(uid=0) by myuser(uid=1000)
Jul 21 07:26:30 myhost su[38863]: (to root) root on pts/5
Jul 21 07:26:30 myhost su[38863]: pam_unix(su-l:session): session opened for user root(uid=0) by myuser(uid=0)
…
Jul 21 07:36:46 myhost polkit-kde-authentication-agent-1[1611]: Dialog cancelled
Jul 21 07:36:46 myhost polkit-kde-authentication-agent-1[1611]: COMPLETED
Jul 21 07:36:46 myhost polkitd[1354]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.freedesktop.login1.suspend for system-bus-name::1.37 [/usr/lib/org_kde_powerdevil] (owned by unix-user:myuser)
Jul 21 07:36:46 myhost polkit-kde-authentication-agent-1[1611]: Completed:  false

So the system wakes up, 5s later you fat-finger the password for the screen locker, 6s after that there seems to be another password mishap but then 16 more seconds later you demonstrate that you need to read the sudo manpage (sudo -i) but it also proves that faillock hasn't kicked in and then, MORE THAN TEN MINUTES AFTER THAT you cancel that weird polkit dialog.

1. does it really and always take so much time between the system resuming and the dialog showing up? (or is there maybe a hidden clock shift)
2. is fat-fingering the lockscreen a pre-requirement (or maybe the trigger) for the dialog?

brachiosnorus · 2024-07-21 09:04:28

Skipping the commentary on sudo, let me answer the questions:

1. The dialog shows up immediately upon resume, but I did not close it immediately. I am in the habit of leaving it open so I can check the details etc in case there is something relevant.
2. Not from my observation/testing.

seth · 2024-07-21 14:41:01

I mostly wanted to point out that it's not faillock, but don't skip, read https://unix.stackexchange.com/question … nd-sudo-su

You could try to intentionally fudge the password and see whether that reliably triggers the issue.
(There might be other vectors but it'd be nice to get this reproducible)

Alternatively: do you have to cross a day or just suspend long-ish to get there?

brachiosnorus · 2024-07-21 19:34:42

Yeah I tested intentionally using the wrong password once, then twice, and with different scenarios (lid close, KDE sleep) but wasn't able to reproduce.

I also had the thought of it being something that occurs overnight, but that'll take a bit longer to establish.

brachiosnorus · 2024-07-23 06:14:33

Yesterday morning the dialog was present but this morning it wasn't, so I don't believe it has anything do to with duration or date.

kyentei · 2024-07-26 13:01:41

Bit of a dead topic, but in case anyone finds this in their search later. I found out I introduced this issue myself by enabling Wayland support in sddm. Once I removed that, suspend no longer asked for a password.

In short, I had a file called /etc/sddm.conf.d/10-wayland.conf with the following content:

[General]
DisplayServer=wayland

brachiosnorus · 2024-07-26 13:22:53

Thanks for the hint.

I was actually thinking of closing this since I haven't seen the dialog in several days (which is unusual) so was wondering if a recent update had fixed whatever was causing it (note that I'm not using the proposed fix from earlier in this thread any longer).

Getting to the SDDM settings ... I don't have Wayland enabled so that also isn't what was affecting me.

seth · 2024-07-26 17:54:46

@kyentei, were you constantly asked for authorization and *BEFORE* the suspend?
brachiosnorus experiences some weird condition where the system suspends but after the wakeup presents a pointless dialog.

@brachiosnorus, the system doesn't enter another sleep if you provide the correct credentials, does it?
Otherwise I'd have said it's related to something *during* the suspend, you're s2idling, do yo configure the system to suspend-then-hibernate or is this just an S2idle?

brachiosnorus · 2024-07-26 20:02:59

No, nothing obvious happened if I provided or didn't provide the extra credentials.

I don't think I configured the system to do anything special when suspending.

seth · 2024-07-31 06:39:14

https://bbs.archlinux.org/viewtopic.php?id=298184 links this to parallel logins?

brachiosnorus · 2024-07-31 07:50:21

For me, that's not it. I am doing a single-user login and experiencing the issue.

I mentioned it not happening in some time, but it still is; I've observed it several times in the past week.

Last edited by brachiosnorus (2024-07-31 07:50:58)

seth · 2024-07-31 14:10:08

Can you reliably reproduce the misbehavior w/ a parallel KDE session (for a different user)?
systemd since recently registers the user session bus as its own session (no, idk why, seems crazy) what threw off optimus-manager and I wonder whether powerdevil might run into the same issue.

w
loginctl list-sessions

I think that started w/ v256 - v255 would the not have the extra session and not exhibit the behavior.

brachiosnorus · 2024-07-31 14:27:41

We might be getting somewhere here.

SESSION  UID USER  SEAT  LEADER CLASS   TTY  IDLE SINCE
      4 1000 me   seat0 979    user    tty2 no   -    
      5 1000 me   -     999    manager -    no   -    
      7 1001 guest seat0 3310   user    tty1 no   -    
      8 1001 guest -     3319   manager -    no   -

I logged in with two sessions, one as my normal user and one with a new user with a more or less blank profile.

I tested KDE sleep twice, once with each user active, and never encountered the dialog.

However, when closing the lid, I was able to reproduce the dialog twice: once with my main user as the active session (the dialog appeared on the new user only) and vice versa.

I then tested closing the lid with just one user logged in and ... no dialog. But as mentioned above it didn't appear every time anyhow, so this is not totally unexpected.

One final note, just judging by the laptop fan, it sounded like the two cases where the dialog appeared took longer to enter sleep mode than the three cases where it didn't.

Last edited by brachiosnorus (2024-07-31 14:28:23)

kyentei · 2024-08-02 20:10:12

@seth Ah, you're right. I was asked *before* suspend.

Arch Linux

#1 2024-07-16 05:06:09

New dialog on KDE "Authentication is required to suspend this system"

#2 2024-07-16 08:27:07

Re: New dialog on KDE "Authentication is required to suspend this system"

#3 2024-07-16 17:41:05

Re: New dialog on KDE "Authentication is required to suspend this system"

#4 2024-07-16 20:57:28

Re: New dialog on KDE "Authentication is required to suspend this system"

#5 2024-07-20 04:39:32

Re: New dialog on KDE "Authentication is required to suspend this system"

#6 2024-07-20 06:20:53

Re: New dialog on KDE "Authentication is required to suspend this system"

#7 2024-07-21 05:48:59

Re: New dialog on KDE "Authentication is required to suspend this system"

#8 2024-07-21 07:31:24

Re: New dialog on KDE "Authentication is required to suspend this system"

#9 2024-07-21 09:04:28

Re: New dialog on KDE "Authentication is required to suspend this system"

#10 2024-07-21 14:41:01

Re: New dialog on KDE "Authentication is required to suspend this system"

#11 2024-07-21 19:34:42

Re: New dialog on KDE "Authentication is required to suspend this system"

#12 2024-07-23 06:14:33

Re: New dialog on KDE "Authentication is required to suspend this system"

#13 2024-07-26 13:01:41

Re: New dialog on KDE "Authentication is required to suspend this system"

#14 2024-07-26 13:22:53

Re: New dialog on KDE "Authentication is required to suspend this system"

#15 2024-07-26 17:54:46

Re: New dialog on KDE "Authentication is required to suspend this system"

#16 2024-07-26 20:02:59

Re: New dialog on KDE "Authentication is required to suspend this system"

#17 2024-07-31 06:39:14

Re: New dialog on KDE "Authentication is required to suspend this system"

#18 2024-07-31 07:50:21

Re: New dialog on KDE "Authentication is required to suspend this system"

#19 2024-07-31 14:10:08

Re: New dialog on KDE "Authentication is required to suspend this system"

#20 2024-07-31 14:27:41

Re: New dialog on KDE "Authentication is required to suspend this system"

#21 2024-08-02 20:10:12

Re: New dialog on KDE "Authentication is required to suspend this system"

Board footer