OOM-killer prevention for master kdeinit process

[Dirk Mueller]

On Wednesday, 2. August 2006 23:21, Lubos Lunak wrote:

>  Ah, damn, of course it is inherited :(. So the adjustment needs to be
> reset right after forking. Hmm, I'm not sure we want kdeinit to stay setuid
> for so long, so I guess that means another setuid helper

It is getting silly. Perhaps we should rather send our brave kernel developers 
a patch for that. It doesn't make any sense to prevent increasing our own oom 
score (integer overflows excluded). It also doesn't make sense for negative 
oom adjustment score to be inherited to childs. Also, I think there is a way 
to allow non-root processes to negate their oom score in a certain range 
without causing a problem, which would totally remove the need for this silly 
suid wrapper. 

> that helper will need some checks to make sure it cannot be misused? Do we
> have already something similar I could base this on?

No idea. 

> > Also, the additional gid's are not dropped
>  Does that mean artswrapper is wrong too? I just used that as a base. And I
> don't think I really know what to fix :).

Euhm, no, silly me. of course all is fine, sine we call exec. I shouldn't 
think about such stuff when not being fully awake anymore. 

However, what we have to ensure is that kdeinit itself, when launched via 
start_kdeinit, does not process any command line arguments or config file 
options that would cause it to launch code / processes directly without 
dropping the OOM killing score. Thats a bit non trivial to achieve, given the 
number of libraries kdeinit links against. Therefore, this helper is really 
really hard to get right. 


Dirk