[KDE/Mac] Review Request 126161: OS X housekeeping

[René J.V. Bertin]

On Thursday November 26 2015 08:54:25 David Faure wrote:

>> No, with "my" fix, applications started through kwrapper appear as individual entries in `ps` listings, with your fix only the `kwrapper5 /path/to/command` entry shows up.
>
>I don't see how that's possible.
>If kdeinit forks, surely you see a separate process for that.

You've got a point, but I don't see how `ps -axxlw | fgrep <command>` can miss something unless it has an unexpected name. Which is possible (I don't think I search for kwrapper instances) but would still mean that `killall` won't work.

I should check the exact parameters given to the execve() call.

>> Also, if your fix does a "real fork + exec", how come it doesn't run afoul of the limitations imposed on that on OS X?
>
>I don't understand this reasoning. Your patch does fork+exec too, except that it executes the helper executable
>(which then loads the kdeinit module) instead of executing the kwrite executable. I don't see how that makes any difference to OSX ?

Yes, the *helper* does that, from within the newly exec'ed process. It's weird, but apparently the exact "forbidden" thing is "fork - call/load non-POSIX APIs - exec" while "fork - exec - call/load non-POSIX APIs" works.
I presume we'd have to dig deep into some very lowlevel OS X code to know what's going on.
BTW, I may be wrong, but from what I understand the crash is provoked intentionally, i.e. it's a sort of abort.

>I don't understand the difference between "execute kwrite" and "execute a proxy executable that dlopens kwrite".

Maybe the above helps a wee bit?

>Not at all, kdeinit on linux does fork+dlopen, no exec.
>But my point is exactly that: if fork+dlopen is a problem on OSX, then don't do it, do fork+exec. That's what you do,
>but then why exec something that will dlopen, instead of exec the real thing?

Ah. Indeed, we have NOT tried the simple fork+dlopen approach, for some reason (your patch skips the `l.load()` step).
However, supposing that it's in fact the dlopen in the child process that's off-limits, relaying it to an exec'ed helper still seems to produce more comparable behaviour.

There's something I don't really understand though: the exact same question you asked above.
What's the difference between starting kwrite directly on the commandline (or through execve()), and dlopen'ing it? Why does the code go through that on Linux? Whatever that difference is, it's probably the reason why the approach fails on OS X.

Final thing: did you see the question about the socket file klauncher leaves behind? Is it possible to let it be removed when klauncher exits?

R.