This is occurring immediately after upgrading Leap 42.3 to 15. When I click the icon of a program to run as a super user (such as System>“File Manager - Super User Mode”) the kdesu “Run as root” box appears asking for the root password. I enter the password and the box freezes and the graphical app is never loaded.
If I run the command from the kdesu “Run as root” box manually in a terminal, this is what I get:
sudo /usr/bin/dbus-launch dolphin -qwindowtitle 'File Manager - Super User Mode'
[sudo] password for root:
kwalletd5: Checking for pam module
kwalletd5: Got pam-login param
kwalletd5: Waiting for hash on 5-
kwalletd5: waitingForEnvironment on: 3
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.
You cannot use sudo for running graphical applications in openSUSE.
Try with “kdesu” or “su -” instead.
Regarding your original problem:
Is this specific to dolphin, or does it happen with e.g. YaST too?
I’ve never seen the password dialog freeze here. But I do remember cases in the past where the app wasn’t started.
Running “xauth -b” fixed that, so maybe try that.
Also try whether this happens on a fresh user account.
PS: this is an X11 session, right?
I’m not completely sure that running applications as root works in Wayland out-of-the-box yet.
It is possibly a hostname issue from the errors. I recommend managing them through YaST.
Under System you can do Network settings. I don’t run Network Manager, but believe you can still set the host name there.
Under Network Services you can use Hostnames to modify your /etc/hosts file. You minimally want:
127.0.0.1 localhost
If you use IPv6 there should be an entry for:
::1 localhost ipv6-localhost ipv6-loopback
Once all that is done make sure your /etc/hostname is correct.
Last resort, but should not be needed:
If as an example if your system obtains its IP from DHCP and the system name is foo.example.com you can modify the localhost line to:
127.0.0.1 localhost foo.example.com foo
It may be a hostname issue, but the errors don’t indicate that.
The errors are just because sudo doesn’t pass the necessary environment, so the app doesn’t find the X display (and other things).
Again, you just cannot run graphical applications via sudo in openSUSE. (unless you adjust the sudo configuration)
If it is a hostname issue, I’d expect applications run as the logged in user not to start as well though.
That’s because Qt didn’t detect that you are running a KDE session (due to the “su -”), and therefore didn’t load the KDE plugin (that would load the KDE settings like icon theme and widget style).
You could try with su alone (without the “-”) and the icons should be there I think.
I didn’t ask the OP to run it as root. I asked him to see if sudo worked. In the past if sudo failed it was because of a hostname issue.
If you go back and look at his post he never even said he tried to run the application with sudo. He tried to run it with kdesu. The sudo part was part of the error it returned.
Finally, i actually googled two lines from the returned error. They both pointed back to a hostname issue. Thus my response.
From your posts I assume that you are missing some background information here. Like Wolfi323 says , it is rather useless to say things like: run as root, but run it as root, …
You asked him to run “sudo su -”, which will run “su -” as root.
I asked him to see if sudo worked. In the past if sudo failed it was because of a hostname issue.
Again, you cannot use sudo to run graphical applications in openSUSE.
This is bound to fail, and doesn’t point to a hostname (or any other) issue at all.
But I understand now that your goal was to see whether sudo works at all.
It does, I suppose, but that’s irrelevant as kdesu actually uses “su” to switch to root (and that does work obviously).
(also, a hostname issue should only affect graphical applications, sudo itself shouldn’t care about the hostname at all I think)
If you go back and look at his post he never even said he tried to run the application with sudo. He tried to run it with kdesu. The sudo part was part of the error it returned.
Wrong, read it again.
He ran the command “sudo /usr/bin/dbus-launch dolphin -qwindowtitle ‘File Manager - Super User Mode’” as a test and that resulted in those errors.
Finally, i actually googled two lines from the returned error. They both pointed back to a hostname issue. Thus my response.
As I said, it may be a hostname issue if applications cannot be started, but then normal applications likely won’t start as well.
Ok, so apparently something just got stuck somehow.
If it happens again, maybe try to kill the process kdesud…
(although, I assume you did logout/login or reboot before and that didn’t help?)
Yes, I tried rebooting and the issue persisted. I did notice there was an additional delay of about 90 seconds during the shutdown phase of the reboot.
Go into your /etc/hosts file and delete your hostname. I’m pretty sure it breaks sudo with a cannot resolve the hostname error. I don’t really feel like breaking my system to find out.
If I recall correctly in the SuSE 8.1 era the YaST install did not default to the systen name of linux and if left blank the default “normal” user could not become root. Today YaST defaults the system name to linux in the install. I have not tried making it blank to see if YaST will allow it and break the system.
You could also break the system back then by not changing the system name correctly in all the right places.
Well, maybe the “xauth -b” then helped indeed to mitigate the problem…
I did notice there was an additional delay of about 90 seconds during the shutdown phase of the reboot.
This may be related I suppose.
If a process gets stuck, it may prevent the unmounting of some filesystems/partitions as it may still have files open/in use.
It will get killed after some timeout, that would explain a certain delay on shutdown (and that timeout is in fact 90 seconds IIANM).
And there are no “cannot resolve the hostname errors” in the OP anyway.
The “could not connect to display” errors are caused by the fact he is using sudo to run the application in the first place, as explained.
This could of course also be caused by problems with the hostname, as the hostname is involved when connecting to the display, but that’s unrelated to sudo (and would likely affect all applications).
Btw, I do use (open)SUSE (or SuSE as it was spelt back then) since 8.1, and don’t remember any such problem with sudo that you refer to.
I observed the same problem the @OP described with dolphin on one of the earliest alpha openSUSE 15/LXQt when opening PCFManager in super user mode (the default file manager in most Desktops not KDE), but was fixed early on.
So,
There is something known that has to work correctly for the icons to display in the file manager running in super-user mode.
And, it’s my personal practice to enable super user mode by launching the file manager from a “su” console rather than invoking from a normal console or clicking on an app launcher menu item.
Update: The issue came back after rebooting. However, after some experimentation, I discovered that disabling autologin (YaST > Security and Users > User and Group Management > Expert Options > Login Settings) completely fixes the issue and proper functioning persists across reboots. If I re-enable autologin, in the issue returns. Any ideas why this would be the case?
Interesting. I would never have thought of that, because I never have (I refuse to) used autologin. I am obviously more paranoid about security than you.lol!
