Version: KDE 4.2.60 (KDE 4.2.60 (KDE 4.3 >= 20090106) (using Devel) Compiler: gcc (Debian 4.3.2-1.1) 4.3.2 / g++ (Debian 4.3.2-1.1) 4.3.2 OS: Linux Installed from: Compiled sources Interestingly, this does not happen each time konsole is lauched. When starting konsole using a button in the panel (command related to that button is "konsole"), the konsole shows up fine and is working correctly BUT plasma opens up a modal dialog with this message: Dialog title: "Sorry - Plasma workspace" Dialog message: "KDEInit could not launch '/home/kde-devel/kde/bin/konsole'." The dialog is modal, that is, all interaction with plasma-related widgets seems blocked. After some seconds the dialog disappears (timed stuff, apparently) and interaction starts again. Congratulations to all KDE developers ! Filippo Rusconi
*** Bug 181522 has been marked as a duplicate of this bug. ***
Please see also my comments on the duplicate bug 181522. There is more information there.
Here's a workaround for the problem of that dialog popping up when there is already a konsole open, and a second konsole is launched from an icon in a folderview or in a panel. It appears that my speculation in bug 181522 is correct, the system generates this error because konsole does not generate a new PID in this case. Some crash detection code is upset, and the popup is produced. So, create a shell script somewhere, say in ~/bin. This script should contain the following text: #! /bin/sh /usr/local/kde4/bin/konsole sleep 10 You may have to change the pathname of konsole. Anyway, if you now point your icons at this script instead of at the konsole binary itself, it satisfies the process creator because it has time to see the newly spawned program. The shell script itself disappears after 10 seconds, of course.
*** Bug 182130 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Here's a workaround for the problem of that dialog popping up when there is > already a konsole open, and a second konsole is launched from an icon in a > folderview or in a panel. It appears that my speculation in bug 181522 is > correct, the system generates this error because konsole does not generate a > new PID in this case. Some crash detection code is upset, and the popup is > produced. > > So, create a shell script somewhere, say in ~/bin. This script should contain > the following text: > > #! /bin/sh > /usr/local/kde4/bin/konsole > sleep 10 > > You may have to change the pathname of konsole. Anyway, if you now point your > icons at this script instead of at the konsole binary itself, it satisfies the > process creator because it has time to see the newly spawned program. The > shell script itself disappears after 10 seconds, of course. This workaround does not work for me. I get the same dialog as before, it just appears 10 seconds later. KDE 4.2, opensuse 11.1.
(In reply to comment #5) > (In reply to comment #3) > > #! /bin/sh > > /usr/local/kde4/bin/konsole > > sleep 10 > This workaround does not work for me. I get the same dialog as before, it just > appears 10 seconds later. KDE 4.2, opensuse 11.1. Interesting. Presumably there is some timeout here. A program that runs for less than a certain number of seconds is considered to have crashed, but one that exits later than this is considered to have done its job and exited or been told to exit by the user. For me, 10 seconds easily suffices, but for you it's not enough. Until the underlying cause is fixed, does somebody have some insight into the conditions under which the program will be assumed to have crashed?
This seems to have been magically fixed for me. I did upgrade my Gentoo system to x11-libs/qt-{core,gui}-4.4.2-r1 and kde-base/kdelibs-4.2.0-r1, but I don't know if that's what fixed it. Something else that might have fixed it is that I deleted ~/.kde4/share/config/session/* while not logged in to KDE, but I think it was still a problem after I did that, so more likely the fix is due to something that changed in Qt or KDE (might even be a Gentoo-applied patch).
I just updated to revision 919730 and recompiled, and this bug appears to have been fixed. I'm hesitant to close the bug myself, since I don't know what change to credit with the fix. It looks like it could be revisions 918657 and 918677, both by dfaure.
Hello, I am having the very same problem with konsole in KDE 4.2.0 (SuSE RPMs) from KDE:/KDE4:/Factory:/Desktop/openSUSE_11.1 repository. The "KDEINIT cannot start /usr/bin/konsole" error dialog only appears if konsole is started from the panel clicking on the konsole icon. Manually starting konsole (from within another konsole) works just fine. Will this bug be fixed in the stable KDE 4.2 tree as well? Ist annoying in a stable release. Thanks Rainer
Revision 920390 and rebuild does not make Konsole work better. The bug seems to still be there; for me, at least. Should I recompile all kdebase? I rebuilt konsole only.
(In reply to comment #10) > Revision 920390 and rebuild does not make Konsole work better. The bug seems to > still be there; for me, at least. Should I recompile all kdebase? I rebuilt > konsole only. > This is not a konsole bug, konsole merely acts in a slightly different manner than other programs, causing this bug to manifest. I'm pretty sure it's a klauncher bug. Rebuild all of kdebase and see if the problem persists.
I rebuilt the whole kdebase and the bug is still there. I'll rebuild EVERYTHING some day to see if that bug dissolves... Thanks for a wonderful desktop.
it was a bug in kdeibs, fixed by dfaure at some point in the 4.2.x timeframe. that said, the dialog if it does show is modal which sucks, but that's a kdelibs thing.
Bug #181477 still exists and is manifesting itself on my system. Running KDE Plasma 5.7 ; root>> trifid:~/status # uname -a Linux trifid 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux Debian buster, updated. as of today. The quicklaunch button is configured and the resulting desktop file is : stephen@trifid:~/.local/share/applications$ cat do-mouse.desktop [Desktop Entry] Categories=System;Utility Comment[en_US]= Comment= Exec=/home/stephen/bin/IPtools/do-mouse GenericName[en_US]=do-mouse click on youtube window GenericName=do-mouse click on youtube window Icon=mlterm-icon-24colors-1 MimeType= Name[en_US]=mouse Name=mouse Path=/home/stephen StartupNotify=false Terminal=false TerminalOptions= Type=Application X-DBUS-ServiceName= X-DBUS-StartupType=unique X-Desktop-File-Install-Version=0.23 X-KDE-SubstituteUID=false X-KDE-Username= the shell script I am launching is very simple and is : #!/bin/bash export DISPLAY=:0.0 /bin/xdotool getmouselocation --shell /bin/xdotool mousemove 2083 551 /bin/xdotool getmouselocation /bin/xdotool click 1 /bin/xdotool mousemove 853 542 /bin/xdotool click 1 and the error message in the dialog is : KDEInit could not launch '/home/stephen/bin/IPtools/do-mouse' which, of course, *does* successfully get launched. What gives?
Is that script executable? xdg-open ~/.local/share/applications/do-mouse.desktop might give more useful output
Created attachment 124658 [details] attachment-7469-0.html yes, the script is executable. And this happens with *any* script I put into the quicklauncher. Stephen On Sun, Dec 22, 2019 at 4:26 PM David Edmundson <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=181477 > > David Edmundson <kde@davidedmundson.co.uk> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|REOPENED |NEEDSINFO > CC| |kde@davidedmundson.co.uk > Resolution|--- |WAITINGFORINFO > > --- Comment #15 from David Edmundson <kde@davidedmundson.co.uk> --- > Is that script executable? > > xdg-open ~/.local/share/applications/do-mouse.desktop > > might give more useful output > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Created attachment 124706 [details] attachment-31734-0.html I am looking at the source code from https://github.com/KDE/kinit I looked at the kdeinit source code and the offending routine is in kinit_win.cpp, launch() // internal launch function 387 int launch(const QString &cmd) 388 { 389 QProcess *proc = new QProcess(); 390 proc->start(cmd); 391 proc->waitForStarted(); 392 startedProcesses << proc; 393 _PROCESS_INFORMATION *_pid = proc->pid(); 394 int pid = _pid ? _pid->dwProcessId : 0; 395 if (verbose) { 396 fprintf(stderr, "%s", proc->readAllStandardError().constData()); 397 fprintf(stderr, "%s", proc->readAllStandardOutput().constData()); 398 } 399 if (pid) { 400 if (verbose) { 401 fprintf(stderr, "kdeinit5: Launched %s, pid = %ld\n", qPrintable(cmd), (long) pid); 402 } 403 } else { 404 if (verbose) { 405 fprintf(stderr, "kdeinit5: could not launch %s, exiting\n", qPrintable(cmd)); 406 } 407 } 408 return pid; 409 } It appears that the pid being returned from the pointer _pid is always zero. Why that is, I have no idea. Unfortunately, I am not set up right now to investigate further. Hope this helps. Stephen On Sun, Dec 22, 2019 at 11:13 PM moose goose <stehen.seldom@gmail.com> wrote: > yes, the script is executable. > > And this happens with *any* script I put into the quicklauncher. > > Stephen > > On Sun, Dec 22, 2019 at 4:26 PM David Edmundson <bugzilla_noreply@kde.org> > wrote: > >> https://bugs.kde.org/show_bug.cgi?id=181477 >> >> David Edmundson <kde@davidedmundson.co.uk> changed: >> >> What |Removed |Added >> >> ---------------------------------------------------------------------------- >> Status|REOPENED |NEEDSINFO >> CC| |kde@davidedmundson.co.uk >> Resolution|--- |WAITINGFORINFO >> >> --- Comment #15 from David Edmundson <kde@davidedmundson.co.uk> --- >> Is that script executable? >> >> xdg-open ~/.local/share/applications/do-mouse.desktop >> >> might give more useful output >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > > > > -- > +++ Maranatha!!! +++ > > Why do all significant things come in groups of 3 ? the Holy Trinity > manifested.... >
Created attachment 124707 [details] error dialogs error thrown by xdg-open
Created attachment 124708 [details] error dialogs error dialog generated from kdeinit
Note that kinit_win.cpp is only used on Windows.
Created attachment 125140 [details] attachment-5499-0.html Thanks! So what equivalent file is used under Linux based systems? I haven't looked yet. On Wed, Jan 15, 2020, 2:11 AM Christoph Feck <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=181477 > > --- Comment #20 from Christoph Feck <cfeck@kde.org> --- > Note that kinit_win.cpp is only used on Windows. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
Ah, I missed that was for Windows only. The error message that I reported actually occurs in klauncher/klauncher.cpp. Here : void KLauncher::requestDone(KLaunchRequest *request) { if ((request->status == KLaunchRequest::Running) || (request->status == KLaunchRequest::Done)) { requestResult.result = 0; requestResult.dbusName = request->dbus_name; requestResult.error = QStringLiteral(""); // not null, cf assert further down requestResult.pid = request->pid; } else { requestResult.result = 1; requestResult.dbusName.clear(); requestResult.error = i18n("KDEInit could not launch '%1'", request->name); if (!request->errorMsg.isEmpty()) { requestResult.error += QStringLiteral(":\n") + request->errorMsg; } requestResult.pid = 0; #if HAVE_XCB if (!request->startup_dpy.isEmpty() && mIsX11) { XCBConnection conn = getXCBConnection(request->startup_dpy); if (conn) { KStartupInfoId id; id.initId(request->startup_id); KStartupInfo::sendFinishXcb(conn.conn, conn.screen, id); } } #endif } if (request->transaction.type() != QDBusMessage::InvalidMessage) { if (requestResult.dbusName.isNull()) { // null strings can't be sent requestResult.dbusName.clear(); } Q_ASSERT(!requestResult.error.isNull()); quintptr stream_pid = requestResult.pid; QDBusConnection::sessionBus().send(request->transaction.createReply(QVariantList() << requestResult.result << requestResult.dbusName << requestResult.error << stream_pid)); } qCDebug(KLAUNCHER) << "removing done request" << request->name << "PID" << request->pid; requestList.removeAll(request); delete request; } Now, I am not sure what all this invovles here, but this is what needs to be looked at.