Bug 181477

*** 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.

This won't happen for me with Plasma 6.