Originally posted by lkcl
View Post
Originally posted by lkcl
View Post
Originally posted by lkcl
View Post
Originally posted by lkcl
View Post
1) Upstart attempts ptrace solution this turned out to work but it also hit performance hard and made programs with anti-debugging fail and when you wanted to debug way harder.
2) Systemd attempted cgroup + PID namespace solution to the PIDFILE problem where you cannot send signals to the right process this turns out to be ponies all the way down(this is a wacky developer quote of the problem).
The systemd PIDFILE solution ponies all the way down.
1) attempt to kill process start termination process inside PID namespace of target.
2)termination process send signal.
3) target process fails to die.
4) termination process locks up
5) go 1 now you have 2 processes to send signals to to kill
Yes a well and truly growing forkbomb the PID namespace stopped from sending signal to the wrong process but ends up when things go wrong with a growing forkbomb.
Mind you the cgroup solution works perfectly for tracking what has started what. Remember when a process is tagged with a cgroup and it loses it parent and gets connected to the PID1 you can query what service this is from. Once you know what service you can look up if that service should be running or not running and make a way smarter move than depinit blind guess.
Originally posted by lkcl
View Post
List of problems
1) PIDFILE problem hits this thing quite hard. Before 5.1 Linux kernel delivering a signal to correct process is kind of pot luck. This does not implement the BSD process protection either. So this broken be you using a Linux or BSD kernel or any other unix/posix kernel made in the past 2 decades..
2) It does not in fact address the process leak problem correctly due to being overly aggressive to make up for not knowing enough.
Depinit along with many other init need to go into the bin of historically broken. Either never used again or someone rewrites to at least deliver signals correctly on bsd kernels and on 5.1 and newer linux kernels. Basically depinit a few K-lines of code that does not work right.
Originally posted by lkcl
View Post
Basically I want init options that when you look at process leak and signal handling in fact stand a chance of working correctly. When you look at init systems for Linux with this requirement the list comes very short very quickly. Systemd and openrc in what you would call init systems. You would also have like docker and other container management solutions.
You really need to read the vote carefully.
Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems.
Its about time we get really strict on the requirements init systems have to pass. After 5.1 Linux kernel correct signal delivery should be expected. Currently correct tracking and handling of process leaks should be expected. Any init system not above this bar should either be scrapped or rewritten.
Yes bsd with jails and correct signal delivery should be expecting super good init system ideas.
I will give you systemd had way more bugs than it should be this is implementation not design issues. Items like depinit on paper implemented ideally with no defects fails on the design table because you don't have enough information in particular places to make sane choices. Fairly much all the init options designs for Linux before systemd falls into the camp of even if ideally implemented is still broken.
Comment