Drakconf aka Control Center "bug" when using icon

[zeebra]

Ok, so I hate to bring this up, especially in the advanced section of this forum, but this issue has been sticking for awhile and I cannot understand what possibly can cause this, and it's becoming somewhat annoying.

It "normally" works.. But.. The higher my uptime, the less likely drakconf is to actually open when pressing the control center icon (KDE panel or start menu). It brings up the password dialog and I type it in, but then nothing opens after that. My workaround is to start drakconf from a terminal and this works just fine, through the same password dialogue as the same user. The icon ofcourse works and there is little that can go wrong with that. But why would the password dialogue (pam? polkit?) fail to (allow)execute the desired program (drakconf) based on starting it from the GUI? It never fails from the terminal. And why is it that a higher uptime makes it less likely for drakconf to start through the GUI?

I can't wrap my head around this issue, it first was quite obscure, but has now carried over from Mageia 5 (or even 4 possibly) into version 7. So the issue definitely exists, and I doubt it is only me. And due to having it for so long, I can now finally put my finger at it as something non-mysterious.

Why would it not even give me an authentication issue if it fails with pam/polkit instead of doing nothing? But it normally works! Just over time the longer the uptime, the more likely it is to fail, which feels very Windows like. A reboot actually solves the issue even!

Maybe some smart minds here can figure this out and understand what mechanics we are talking about exactly. What's in play here and why does it fail/go wrong? Is there possibly a fix for it then, I'd hope so. It's not a big issue, just one preventing perfection.

[doktor5000]

FWIW, this is actually a pretty basic topic, hence I moved it to the appropriate subforum.

Most often it boils down to the fact that no proper hostname has been set, and hostname will be accepted from the router via DHCP.
As the authentication of X applications is bound to the hostname, when the hostname is updated then this authentication is usually invalid.
And the mechanism to notify userspace (e.g. your running desktop session) about the hostname change to adapt to that is sometimes not working depending on what network applet you're using.
See https://bugs.mageia.org/show_bug.cgi?id=3782 and maybe https://bugs.mageia.org/show_bug.cgi?id=16764 for some more details.

Also please provide the output of the following commands, run as your regular user in a terminal:

Code: Select all

loginctl show-session $XDG_SESSION_ID
ps -ef|grep -v grep|grep -iE "polkit|policykit"
pkexec whoami     # you need to enter your root password when asked by the authentication dialog
echo $DISPLAY
xauth list
cat /etc/hostname

and as root from:

Code: Select all

systemctl status polkit.service -a

[zeebra]

If it's any help I run net_applet. It is a bit strange, because normally I do set my hostname but I noticed now it's set as localhost.

It's working right now, but my take is that in a few days (2-8 days) it will no longer. Once that happens I guess a way to check is that polkit.service status lookup to see if that gives any authentication error. I guess the only authentication I ever do via the GUI is drakconf actually.

I'll do a diff on all those once the issue appears and try to figure out the exact cause. Those links will surely help, it's probably the hostname issue.

[doktor5000]

Once that happens I guess the most useful way to figure it out is that polkit.service status lookup to see if that gives any authentication error.

No, as polkit itself is usually not a problem, the problem is mostly with the X authentication, as explained above.

[zeebra]

Yeah, but now I have something (various) to look into and an idea what it could be, before it was just a mystery. I didn't even know which mechanics was behind the whole thing (GUI/authentication/drakconf).

[zeebra]

Policykit does indeed successfully authenticate despite the problem having reappeared. Sadly I had 1 reboot between then and now for some reason, so the magic cookie has naturally changed. I guess I'll have to reboot again and keep my eyes open on the same boot, same issue.

Loginctl "leader" was the only thing that changed, without that saying much, probably also due to the reboot? Display always remained the same. Hostname is still the same default localhost, as I did not set it (yet) during this update process nor after.

Not sure that you are looking for with that ps grep grep grep, as it didn't work the first time I used it and not now either. I used a simpler version, but I guess you were looking for something specific.

The authenticate and execute dialogue always worked through the terminal previously as well, and I was not surprised that "pkexec whoami" worked as expected also when drakconf does not open through the GUI, only through terminal emulator.

[doktor5000]

Hostname is still the same default localhost, as I did not set it (yet) during this update process nor after.

Well you did not set it, but if you get your IP via DHCP chances are that this is also changing your hostname. I'd simply set a hostname properly once to avoid issues like that.

Not sure that you are looking for with that ps grep grep grep, as it didn't work the first time I used it and not now either. I used a simpler version, but I guess you were looking for something specific.

What do you mean it didn't work?
I just want to know what polkit agent you're using.