Hmm. Probably I'm still missing something obvious, but how does this
help for existing services like databases and/or closed-source products?
Or do you mean to provide this as a library
(s@main@__attribute__((constructor)) my_main@ then) and link (or even
preload) to the programs people want to change limits on-the-fly in?
(And clone with THREAD flag to share task_struct->signal.)
But this approach can only help for the parent of all the forked-later
processes. Especially if a process forks and exits (i.e. creates a
daemon), the child running in the background doesn't have the
wait_for_message thread. So if it forks again (e.g. to service a new
request) the limits cannot be changed in any of them.
This can be solved by adding such a cloned-thread loop into every forked
child, but I'm not sure this is something we want.
In addition, people don't know which process will need to change limits
in advance. Every single binary would have to contain such code.
--
js
--