Bug 431939

Summary: [Systemd]When synchronizing settings with SDDM, password prompt disappears on it's own
Product: [Applications] systemsettings Reporter: Matej Mrenica <matejm98mthw>
Component: kcm_sddmAssignee: David Edmundson <kde>
Status: RESOLVED DUPLICATE    
Severity: normal CC: kde, matejm98mthw, nate, plasma-bugs
Priority: NOR    
Version: 5.20.90   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:

Description Matej Mrenica 2021-01-22 16:55:25 UTC
STEPS TO REPRODUCE
1. Go to SDDM settings
2. select "Synchronize settings"
3. confirm with "Synchronize" button
4. A dialog to enter user password opens, but...

OBSERVED RESULT
It disappears in ~3 seconds regardless of whether user enters the password. And the synchronization won't continue.

EXPECTED RESULT
User is able to enter the password and synchronization is done.

SOFTWARE/OS VERSIONS
KDE Frameworks Version: 5.78
Qt Version: 5.15.2
Comment 1 Nate Graham 2021-01-26 06:16:56 UTC
Hmm, works for me.
Comment 2 Matej Mrenica 2021-01-26 11:18:50 UTC
Could you retest with the new systemd startup enabled? I had it enabled before but after I disabled it, I don't have this issue anymore.
Comment 3 Matej Mrenica 2021-01-27 10:15:31 UTC
The same issue is also present when trying to save a file that requires user password, e.g. /etc/fstab.
Comment 4 David Edmundson 2021-01-27 10:40:34 UTC
Please confirm if polkit-kde-agent1 is running.

This was broken with the systemd boot in the beta but is fixed in master
Comment 5 Matej Mrenica 2021-01-27 11:08:34 UTC
If you mean polkit-kde-authentication-agent-1 then yes, otherwise no.
Comment 6 David Edmundson 2021-01-27 11:21:23 UTC
Yes, that. Thanks
Comment 7 David Edmundson 2021-01-27 11:24:20 UTC
Job for plasma-polkit-agent.service failed because a timeout was exceeded.
See "systemctl --user status plasma-polkit-agent.service" and "journalctl --user -xe" for details.


Aha.

So it starts, systemd thinks it didn't, and then kills it.
Comment 8 David Edmundson 2021-01-27 11:28:43 UTC
I believe this is fixed in master

*** This bug has been marked as a duplicate of bug 431963 ***