Comment 2 for bug 1579837

Ah, OK. This seems to be due to the new addition of policykit-unity8.

ubuntu-system-settings registers its own policykit agent to handle changing password modes (because a system one didn't exist before, and because the UI design for the password change screen in System Settings involved asking for the password directly in the dialog, not via a separate policykit dialog.

So it spins up its own agent temporarily and feeds it the password to expect. And shuts down the agent when done.

However, in this case, there is already an agent registered. So USS bails on its attempt to change the password mode.

But AccountsService in the meantime IS trying to talk to policykit-unity8 to ask it if it's OK to let the user change the password mode. But it's trying to talk to unity8 to show a password snap decision. Which is synchronously in the middle of this password mode call. So it freezes instead.

Ugh. So I'm going to talk to the policykit-unity8 folks about this and see the best way forward.

If we *need* a quick fix, unseeding policykit-unity8 should do it.