Am 2017-02-21 12:48, schrieb Harald Sitter:
# startplasmacompositor
- Resolves qdbus via qtpaths which is not relocatable, that's not
really our fault and probably not too easy to solve or even worth it.
Finding qdbus reliably has been a long standing problem unfortunately.
- Hard-compiles the kwin_wayland path. I think this is actually
security relevant and necessary. startplasmacompsitor would already
have a user environment, so it could have a bad PATH with a
kwin_wayland ontop of the actual kwin_wayland. I'd actually find it
better if this script got replaced by kwin_wayland or a C/C++ helper.
If /bin/sh is a symlink to /bin/bash the environment easily can be
full of rubbish from the user session which may or may not be seeking
to exploit kwin.
Nah that doesn't belong into KWin - it would create a dependency loop.
Personally I would prefer a systemd-user session approach or something
in that way to get away from the shell scripts.
- Hard-compiles the startplasma path
# xwayland
Xwayland is simply not relocatable as xkbcomp's full path is
hard-compiled.
That should then also apply to kwin itself. At least if we want to get
the layout flags into the sni we will have to hard compile in the
evdev.xml path which I think is what is the case with xkbcomp's full
path?
# startplasma
- Actually executes qdbus from PATH where startplasmacompositor took
great care to grab it from qpaths, that seems silly. I am thinking
either both should run from PATH or none.
- Hard-compiles start_kdeinit_wrapper
- Hard-compiles ksmserver
# kinit
$ ls -lah /usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit
-rwxr-xr-x 1 root root 11K Feb 14 18:22
/usr/lib/x86_64-linux-gnu/libexec/kf5/start_kdeinit
Well, that's a lie. Probably incorrectly ported somewhere along the
line.
Of just no longer needed. If we worked three years without anyone
noticing breakage we can go for the Xorg deprecation model. (For those
not knowing: break by accident, remove once you notice it's broken
without a single bug report several years later)
But I hear you asking what the point of start_kdeinit is. Comment
again:
Prevent getting killed by bad heuristic in Linux OOM-killer.
This wrapper decreases the chance OOM killer kills it (or its
children,
namely kdeinit)
Yeah, that's not really working now is it.
$ cat /proc/`pidof kdeinit5`/oom_*
0
1
0
More importantly this makes no sense. See reference table from above,
everything depends on kwin_wayland, kwin_wayland doesn't OOM adj, so
whether or not kdeinit is OOM adjusted is fairly irrelevant as kwin
might get murdered causing everything to get murdered. (Xorg isn't
decreased either, so same there).
But let's take step back here. start_kdeinit wants to OOM adjust so
that it doesn't get murdered. How old is this code?
Fair guess: 1996
In kernel 2.6.39 already the score is documented as a value of
badness. Over simplified: the more memory a process uses, the worse
its score, the more likely is it to get killed during OOM handling.
So, how in the world would kdeinit5 have such a bad score that it gets
murderd?
This entire construct makes no sense to me and should be dropped, the
way I see it this is overengineered nonsense.
or 1996, but same result ;-)
# kdeinit5
- Hard-compiles path to klauncher
- Should be dropped in favor of dbus activation or systemd socket
activation (slightly out of scope, I know ;))
# ksmserver
Starting here things seem to largely not be hardcoded anymore. Rejoice!
# conclusion
- startkdeinit is making me angry
- We have a real problem with libexec. 90% of hardcompiled paths I
tend to find are frameworks things that need to run something from
libexec. Hardcompiling seems like a massive hack for finding where
your libexec is. I am not sure how to best resolve this, but I'd
imagine QStandardPaths could do with an extension to handle paths
within library paths.
The porting guide for everything libexec from KStandardDirs was hard
compile.
We have a few valid cases with libexec, e.g. kscreenlocker_greet to
kcheckpass, or kwin to kscreenlocker_greet, but that's it.
Nice investigation!
Cheers
Martin
