Thanks for the quick review!
I also created a related issue report here:
https://bugs.kde.org/show_bug.cgi?id=386886
which can of course be closed once the patch has landed.

If you add the following (upper-case with a colon and space) on its own line in your commit message the bug will be automatically closed once it landed:

BUG: 386886

In D8806#167404, @broulik wrote:

If you add the following (upper-case with a colon and space) on its own line in your commit message [...]

Many thanks, done!

Do you have commit access?

Just for the record, how does Konsole inherit this fd when BluezQt is only used in plasmashell + kded and KDE apps are afaik not forked from these processes?

In D8806#167457, @bshah wrote:

Do you have commit access?

In case you are adressing me: No.

In D8806#167483, @drosca wrote:

Just for the record, how does Konsole inherit this fd when BluezQt is only used in plasmashell + kded and KDE apps are afaik not forked from these processes?

What exactly happens depends on how Konsole is started.
If it's started via plasmashell (e.g. menu), the process tree is:

kdeinit5: Running...
 \_ /usr/lib64/libexec/kf5/klauncher --fd=9
 \_ kded5 [kdeinit5]
 \_ /usr/bin/ksmserver
 |   \_ /usr/bin/kwin_x11 -session 10cf9da065000150283451700000087800055_1510626492_975085
 |   \_ /usr/bin/plasmashell
 |   |   \_ /usr/bin/konsole
 |   |       \_ /bin/zsh
 |   |           \_ ps faux

If you register a custom shortcut to start a terminal and launch Konsole via that, you end up with:

kdeinit5: Running...
 \_ /usr/lib64/libexec/kf5/klauncher --fd=9
 \_ kded5 [kdeinit5]
 |   \_ /usr/bin/konsole
 |       \_ /bin/zsh
 |           \_ ps faux
 \_ /usr/bin/ksmserver

So it's either forked from plasmashell or kded on my system at least.

The issue has also been observed before: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860269
but sadly the fix got lost in the Debian bugtracker.

Alright, thanks for the explanation.

I need your full name and e-mail to commit it (I can't get it with arch patch probably because you didn't upload this review with arc diff).

In D8806#167503, @drosca wrote:

I need your full name and e-mail to commit it (I can't get it with arch patch probably because you didn't upload this review with arc diff).

Oliver Freyermuth <o.freyermuth@googlemail.com>

Didn't know about arc just yet, but will use it for future work, thanks for the hint!

I do wonder if this is security fix? And should probably be handled like that?

In D8806#167509, @bshah wrote:

I do wonder if this is security fix? And should probably be handled like that?

Why? It's not like any other process can't open /dev/rfkill as we ship udev rule to enable r+w access to /dev/rfkill for all users.

In D8806#167510, @drosca wrote:

Why? It's not like any other process can't open /dev/rfkill as we ship udev rule to enable r+w access to /dev/rfkill for all users.

My comment was question :-)

But well I didn't know about udev rule.. in that case it's fine

Though on the other hand, why isn't KLauncher (KRun) used for running apps everywhere? This way they are forked from kdeinit5 and this issue is non-existant.

Quick test:

• Launch from taskmanager -> forked from plasmashell
• Launch from quicklaunch applet -> forked from kdeinit
• Launch from krunner -> forked from ksmserver
• Launch from global shortcut -> forked from kded

... because this isn't kde4 anymore, where almost every app provided a kdeinit module.

QProcess forks from the process that uses QProcess, it might look inconsistent when looking at process trees but it's really the most standard Unix way of executing processes: forking ;)
kdeinit was the non-standard way...

For dependency reasons, not everything provides a kdeinit module anymore.
It's also very unclear still whether kdeinit brings any performance benefits in 2017.
We're still looking for someone to take the time to properly benchmark that, the last time this happened was 10 years ago at least.

Not to spam this review request:

We're still looking for someone to take the time to properly benchmark that, the last time this happened was 10 years ago at least.

FWIW: I did a very very basic test recently.
I put Q_BENCHMARK round QProcess, and using kinit via KToolInvocation to launch dolphin. Dolphin at least links kinit, not sure if it really works.
Then used KWindowSystem to wait for a window to be added, which seemed a real-world test of "readiness".

Results were near identical. If anything via KToolInvocation was slower, but it had an extra internal KService lookup so not a completely fair test.