Unable to launch YaST2 from KDE menu

English Applications
#1

I have upgraded Open Suse to 13.1 (kde 4.11.5) using the online upgrade on a headless workstation. It is configured as a firewall/router for two networks. I access it via VNC. Most things seem to work just fine with the exception of YaST2 which won’t launch from either the menu or from the “system settings”. From the former it opens up a tab on the bottom of the screen and shows a bouncing YaST icon for about 10 seconds which then vanishes as does the tab. On the latter it tells me that “yast is an external application that has been launched” (it hasn’t). In neither of these two cases is anything written in /var/log/YaST2/y2log

This is not super important, just irritating, since I can easily launch it from the command line using yast --qt when root. It behaves ok then although launching any of the sub-applications does result in "Unknown config. Invalid snapshot ''each launch. I have looked this up and it seems that they are harmless, having something to do with snapper which I have not configured. I did try using yast --gtk but it tells me that gtk is unavailable and defaults to qt. Launching it without options gives me the text version OK. If I launch it without being root it just tells me that I can only do non-root things.

When I launch it via the command line much gets written to the log.

This leads me to the slight suspicion that it might be something to do with the inability of the launcher to ask me to type in the root password, but I haven’t the faintest idea how to go about debugging that.

If someone has an idea where I should look, I would be obliged, bearing in mind I do have a command line workaround.
Thanks in advance.

#2

Do you have a " character (double quote) in your root password?
There’s a bug in KDE where starting programs as root doesn’t work in this case:
https://bugs.kde.org/show_bug.cgi?id=334083

So try to change your root password to something else.

#3

Thankyou for responding but I have no quotes in the root password

#4

Ok.

So you said it works fine when started from the terminal.
How did you exactly launch it in that case? (with “su -” I suppose?)

Does “kdesu /sbin/yast2” work in the terminal? If not, what output do you get?

#5

On 2014-05-12 10:26, sanktwo wrote:
>
> I have upgraded Open Suse to 13.1 (kde 4.11.5) using the online upgrade
> on a headless workstation. It is configured as a firewall/router for two
> networks. I access it via VNC. Most things seem to work just fine with
> the exception of YaST2 which won’t launch from either the menu or from
> the “system settings”. From the former it opens up a tab on the bottom
> of the screen and shows a bouncing YaST icon for about 10 seconds which
> then vanishes as does the tab.

KDE tries to start an application, which doesn’t, and KDE times out and
stops trying; then it removes the tab and hourglass or whatever mouse
icon configured for wait. You can increase the timeout: years ago I had
to do that on a slow computer or many programs failed to start.

> On the latter it tells me that “yast is
> an external application that has been launched” (it hasn’t). In neither
> of these two cases is anything written in /var/log/YaST2/y2log
>
> This is not super important, just irritating, since I can easily launch
> it from the command line using yast --qt when root. It behaves ok then
> although launching any of the sub-applications does result in "Unknown
> config. Invalid snapshot ''each launch. I have looked this up and it
> seems that they are harmless, having something to do with snapper which
> I have not configured.

Ah! I wondered about that one. So that’s what it is… I often run “yast
–qt” from other, non-kde, desktops, and got that message.

Thanks! :slight_smile:

> I did try using yast --gtk but it tells me that
> gtk is unavailable and defaults to qt. Launching it without options
> gives me the text version OK. If I launch it without being root it just
> tells me that I can only do non-root things.
>
> When I launch it via the command line much gets written to the log.
>
> This leads me to the slight suspicion that it might be something to do
> with the inability of the launcher to ask me to type in the root
> password, but I haven’t the faintest idea how to go about debugging
> that.
>
> If someone has an idea where I should look, I would be obliged, bearing
> in mind I do have a command line workaround.
> Thanks in advance.

I’m not sure if what I observe on one of my computers is related to your
problem or not, but I’ll mention it in case it gives you or anyone ideas.

I use the LXDE desktop. My usual procedure is to keep a terminal where I
do “su -” and run root commands from there. Well, graphical yast does
not start, I always get the ncurses version failback, no matter if I
call yast, yast2, YaST2, “–qt”, whatever.

My workaround is not to use “su -”, but “ssh -X root@localhost”
instead… which works just fine to invoke “yast --qt”.

No idea why. Related to your problem? Dunno. You are using VNC…
Perhaps what fails is the needed authorization to use the current
graphical display as root, like in my case.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#6

Yes, I just su to root then from a root shell did yast --qt

If I do “kdesu /sbin/yast2” from normal login, nothing at all happens (I ctrl C out of it). If I su first then I get:

kdesu /sbin/yast2
kdesu(23354)/kdeui (kdelibs): Session bus not found 
To circumvent this problem try the following command (with Linux and bash) 
export $(dbus-launch) 
KCrash: Application 'kdesu' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
sock_file=/root/.kde4/socket-linuxtwo/kdeinit4_linuxtwo.heuchin.bingen.org_1
Warning: connect() failed: : No such file or directory
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi directly
drkonqi(23355)/kdeui (kdelibs): Session bus not found 
To circumvent this problem try the following command (with Linux and bash) 
export $(dbus-launch)

I then did what it said and executed “export $(dbus-launch)” and re-did kdesu /sbin/yast2
It launched Yast but with a large output to the terminal. Still no launch from the menu though. Here is the output:

kdesu /sbin/yast2
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kbuildsycoca4 running...
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419) KConfigGroup::readXdgListEntry: List entry Keywords in "k3bsetup.desktop" is not compliant with XDG standard (missing trailing semicolon). 
kbuildsycoca4(23419)/kdecore (services) KServicePrivate::init: The desktop entry file "/usr/share/applications/YaST2/timezone.desktop" has Type= "Application" but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files. 
kbuildsycoca4(23419)/kdecore (services) KServicePrivate::init: The desktop entry file "/usr/share/applications/YaST2/restore.desktop" has Type= "Application" but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files. 
kbuildsycoca4(23419)/kdecore (services) KServicePrivate::init: The desktop entry file "/usr/share/applications/YaST2/samba-client.desktop" has Type= "Application" but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files. 
kbuildsycoca4(23419)/kdecore (services) KServicePrivate::init: The desktop entry file "/usr/share/applications/YaST2/backup.desktop" has Type= "Application" but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files. 
kbuildsycoca4(23419)/kdecore (services) KServicePrivate::init: The desktop entry file "/usr/share/applications/YaST2/mail.desktop" has Type= "Application" but also has a X-KDE-Library key. This works for now, but makes user-preference handling difficult, so support for this might be removed at some point. Consider splitting it into two desktop files.

(the last line repeated for hundreds of lines)

It finished with the line “kbuildsycoca4 running…”

Does that give you any hints as to how to fix the problem?

#7

OK, I will look at increasing the timeout. However, I have to say that launching it from the terminal only takes a second or two. More later…

#8

After doing just “su” you cannot run graphical applications because they don’t find the KDE session (and especially the dbus session).
Just use “su -” and it should work.

But it makes no sense to kdesu as root anyway, since it’s point is to run an application as root.
If you are already root when running “kdesu xxx” kdesu does nothing of course.

It launched Yast but with a large output to the terminal. Still no launch from the menu though. Here is the output:

kdesu /sbin/yast2
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kbuildsycoca4 running...
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher. 
kbuildsycoca4(23419)/kdecore (KSycoca) KSycocaPrivate::checkVersion: Found version 229 , expecting version 230 or higher.

This could point to a mismatch in KDE packages.
But as this was for root, I suppose root’s sycoca is just outdated, and kbuildsycoca4 was called the last time with a previous KDE version.

So I guess we can ignore that.
If that was the problem, you probably couldn’t start any KDE application at all, not even as user.

(the last line repeated for hundreds of lines)

It finished with the line “kbuildsycoca4 running…”

That doesn’t matter, that’s just debugging output from “kbuildsycoca4”.
Since you ran a KDE application as root, it had to create the sycoca (SYstem COnfiguration CAche) for root, where KDE stores which .desktop files exist f.e.

Does that give you any hints as to how to fix the problem?

Not really.
I think the biggest clue ATM is that “kdesu /sbin/yast2” just hanged.
Could you try to kill “kdesud” before you run “kdesu /sbin/yast2”? And please run “kdebugdialog” before that and enable everything related to “kdesu”.
And please run it as user, i.e. without “su”. Otherwise it’s meaningless.

#9

I doubt that whis would help anyway.

That “timeout” is only how long the icon animation/taskbar entry should be shown at maximum. It doesn’t have anything to do with actually starting the application, and has no effect when you start it in the terminal anyway.

I.e.: KDE does not kill the application if it is not ready after a certain time, or anything like that.

#10

On 2014-05-12 18:06, wolfi323 wrote:

> I.e.: KDE does not kill the application if it is not ready after a
> certain time, or anything like that.

When I had this problem time ago, it did indeed kill it. It was KDE 3,
perhaps even KDE 2.

Things like firefox would start from terminal, but not from menu, and
both methods took a minute or two. It was a slow machine. I increased
the timeout, and those programs started.

But I doubt that is the OP problem.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#11

oops, sorry, me just being thick - I should have guessed about the su at the end of the command. :embarrassed:

WOW, something happened! When I killed kdesud lots and lots of windows opened up, all in the same place asking me to give the root password for launching yast! I cancelled them all (must have been about 10). I guess all these were queued up as a result of my experiments. I suppose that you were expecting kdesud to re-spawn more or less immediately after I did a “kill 9 19722” (i.e. the process number at the time)?

I ran “kdesu /sbin/yast2” as a normal user. I got the debug output below and it opened up a window asking for root password. Yast launched successfully.

kdesu(24538)/kdesu (kdelibs) KDESu::PtyProcess::exec:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/process.cpp : 293 ]  Running "/usr/bin/su"
kdesu(24538)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/su.cpp : 259 ]  Read line "Password: "
kdesu(24538)/kdesu (kdelibs) KDESu::PtyProcess::exec:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/process.cpp : 293 ]  Running "/usr/bin/su"
kdesu(24538)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/su.cpp : 259 ]  Read line "Password: "
kdesu(24538)/kdesu (kdelibs) KDESu::PtyProcess::WaitSlave:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/process.cpp : 379 ]  Child pid 24546
kdesu(24538)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/su.cpp : 259 ]  Read line ""
kdesu(24538)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/su.cpp : 259 ]  Read line "kdesu_stub"
kdesu(24538)/kdesu (kdelibs) KDESu::PtyProcess::exec:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/process.cpp : 293 ]  Running "/usr/bin/su"
kdesu(24538)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/su.cpp : 259 ]  Read line "Password: "
kdesu(24538)/kdesu (kdelibs) KDESu::PtyProcess::WaitSlave:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/process.cpp : 379 ]  Child pid 24551
kdesu(24538)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/su.cpp : 259 ]  Read line ""
kdesu(24538)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU:  /home/abuild/rpmbuild/BUILD/kdelibs-4.11.5/kdesu/su.cpp : 259 ]  Read line "kdesu_stub"

When I closed yast kde returned to the command prompt with no further messages.

However, (and I don’t know whether you are going to like this…) - the problem has vanished. I can now launch yast from the menu and from “system settings”. It would seem that you have resolved the problem. Something was screwed up in kdesud. I just have to remember the magic incantation of killing kdesud should it happen again.

Many thanks for your efforts, I am just a kde user so I really appreciate your expertise.

#12

Yes. Actually it is (re)spawned when you run “kdesu” if it is not running already.

Those messages you got are just debug output, I see nothing unusual there.

However, (and I don’t know whether you are going to like this…) - the problem has vanished. I can now launch yast from the menu and from “system settings”. It would seem that you have resolved the problem. Something was screwed up in kdesud. I just have to remember the magic incantation of killing kdesud should it happen again.

Yes. Apparently kdesud got stuck somehow.
After you killed it, it got restarted since there were still pending kdesu requests, and could process all those requests.

Why it got stuck I cannot tell unfortunately.
I must admit that something like that never happened to me before. (I haven’t used KDE over VNC any more since a few years ago though)