Bug 354151

The same happens to me.

I'm using Kubuntu 15.10 with kio 5.15.0

Adding to this. A possible workaround I tried was to set a different mail client on "Default Applications" settings to a terminal program that redirect to null, but the setting is not followed, with KMail installed or not.

Bug affects me too:

while : ; do ps -ef | grep kmailservice ; done # produces the folllowing output

wesleys   9792  9786  0 10:25 ?        00:00:00 /usr/bin/kmailservice5 mailto:Zaaksysteem-frontend@2.0.0
wesleys   9792  9786  0 10:25 ?        00:00:00 /usr/bin/kmailservice5 mailto:Zaaksysteem-frontend@2.0.0
wesleys   9812  9806  0 10:25 ?        00:00:00 /usr/bin/kmailservice5 mailto:Zaaksysteem-frontend@2.0.0
wesleys   9812  9806  0 10:25 ?        00:00:00 /usr/bin/kmailservice5 mailto:Zaaksysteem-frontend@2.0.0
wesleys   9832  9826  0 10:25 ?        00:00:00 /usr/bin/kmailservice5 mailto:Zaaksysteem-frontend@2.0.0
wesleys   9832  9826  0 10:25 ?        00:00:00 /usr/bin/kmailservice5 mailto:Zaaksysteem-frontend@2.0.0

To kill it properly: 
while : ; do ; pkill -9  kmailservice ; done
That will kill the process (your mouse pointer will stop bouncing, yay).

I can confirm this as well, on a current openSUSE Tumbleweed. The bug itself is described here:
http://askubuntu.com/a/702151

Both xdg-open and kde-open5 processes are spawned in an infinite loop every time you accidentally click on a mailto: link when no email client is installed, causing a resource drain, bouncing cursor and no way to stop it via KSysGuard (have to do an infinite kill loop like Wesley suggested to stop it).

Bug 344527 seems to be generally the same issue.

I have the same issue, and IIRC it was also present on KDE4.

Yes this affects me too. Thanks for the workaround.

I can see this bug even if KMail is not set as the email client. I use Thunderbird and still encounter this error.

Bug still actual.

Confirmed. The steps for me to reproduce this (with a self-compiled KF5 in a separate prefix) are:

kcmshell5 componentchooser          # and set the default mailer to "doesnotexist"
export PATH=/usr/bin:$KDEDIR/bin     # to avoid any kde4 binaries in the PATH (*)
rm $KDEDIR/bin/kmail                       # to avoid a fallback on kmail
kde-open5 mailto:foo@example.com       # fork bomb happens
rm $KDEDIR/bin/kmailservice5         # to stop the fork bomb

What is happening is:
kde-open5 -> KRun => kmailservice5 -> QDesktopServices => xdg-open => kde-open5 -> .....
 ("->" is a method call, while "=>" means "starts another process")

Basically everything in there is delegating the decision of what to open to something else ;-)

When I ported kmailservice5 to QDesktopServices, I was assuming that KRun would never end up calling kmailservice5 but the actual mail client.
KRun, for mailto URLs (and other 'helper protocols'), selects the app associated with x-scheme-handler/mailto if there is any, and otherwise falls back to the one listed in mailto.protocol, which is kmailservice5.

OK then the solution is for kmailservice5 to not use QDesktopServices, but only do "pick the app associated with x-scheme-handler/mailto", to avoid any fallback to kmailservice like KRun would do. Patch coming up. Of course the expected result will be an error message box, what else can we do if there is no mail client installed at all.

(*) this is because I don't have kde4 stuff in /usr/bin but in a separate prefix; the same bug happens without /usr/bin in the PATH, but then QDesktopServices calls kfmclient exec instead of xdg-open.

OK it gets worse. kmailservice5 isn't listed in a .protocol file, but instead it's defined as an application associated with x-scheme-handler/mailto. Doh. Recursive logic.

There is in fact no more mailto.protocol file.

I now think the best solution is just to kill kmailservice5 completely. The mechanism defined by XDG (looking up what is associated with x-scheme-handler/mailto) and used by the KCM (it saves the chosen app into mimeapps.list using that 'mimetype'), and used by KRun to pick up the app... means that there is no need for a generic executable like kmailservice5 anymore.

If that's the consensus, then I can help on the xdg-utils side of things (to remove it's use of kmailservice5 too)

I don't follow. xdg-utils doesn't know about kmailservice5, does it? It only knows about kde-open5, so nothing needs to be changed at the xdg-utils level, unless I'm missing something.

By simply removing kmailservice5, that's one less app associated with x-scheme-handler/mailto, so either you have any other mailer installed, or you have none and KIO will pop up a message box (I'm fixing KIO -- and Qt -- for this to happen).

Git commit 2e6980e9ba3b91798dad0db9f9d78317b2d7e4a2 by David Faure.
Committed on 22/04/2016 at 14:57.
Pushed by dfaure into branch 'master'.

Remove kmailservice5, it can only do harm at this point.

With no other mail client installed, it would trigger an infinite loop:
kde-open5 => kmailservice5 => xdg-open => kde-open5 ...

The mechanism defined by XDG (looking up what is associated with x-scheme-handler/mailto)
and used by the KCM (it saves the chosen app into mimeapps.list using that 'mimetype'),
and by KRun to pick up the app... means that there is no need for a generic executable
like kmailservice5 anymore. It was only useful for kdelibs4's .protocol files, which
the x-scheme-handler mechanism replaces.

FIXED-IN: 5.22

M  +0    -1    src/ioslaves/CMakeLists.txt
D  +0    -11   src/ioslaves/mailto/CMakeLists.txt
D  +0    -38   src/ioslaves/mailto/kmailservice.cpp
D  +0    -57   src/ioslaves/mailto/kmailservice5.desktop
M  +9    -1    src/widgets/krun.cpp

http://commits.kde.org/kio/2e6980e9ba3b91798dad0db9f9d78317b2d7e4a2