Additionally Alan Cox weights in on how *not* to do changes, using GNOME 3 as an example.This is an excerpt from ELCE 2011 kernel development panel with Linu...
Process monitoring, in the basic sense, is seeing if a process is running. You mean how they handle dependency trees/graphs ? From what i just read sysD targets are groups that can have other groups in them (aka inherit, aka “services”, aka compose). I wonder if that is the core of the problem. Not that i care, that’s the hole they dug for themselves when they insisted only pid EINS can orchestrate cgroups (didn’t use to be).
Either way, in the overwhelming majority of use cases they are practically the same.
Bdw, i didn’t downvote you. I reserve it only for the most irrational fans, aka parroting fanboys.
One of the big issues with process monitoring, in the general sense, is how PID 1 checks on processes
The cgroups usage lets them make use of a very powerful Linux-specific feature.
Some competitors such as Upstart tried to use ptrace for this, but that causes services to run slower
“Is a process running” I think is a harder question than you realize. systemd also offers the ability to ask “is a process running correctly” through watchdogs, and “is a process using too much memory” or “is a process using too much CPU” and offer corrective action if they are
The systemd.target issues I mention are related to different design goals. Systemd tries to start as many services as possible at once, but we need some services up within 1 second, and the rest can take longer
One option I offered was a modification to systemd so that targets could handle Before/After during our design, but the maintenance of porting it over for each update versus using OpenRC was decided to be too much effort
Process monitoring, in the basic sense, is seeing if a process is running. You mean how they handle dependency trees/graphs ? From what i just read sysD targets are groups that can have other groups in them (aka inherit, aka “services”, aka compose). I wonder if that is the core of the problem. Not that i care, that’s the hole they dug for themselves when they insisted only pid EINS can orchestrate cgroups (didn’t use to be).
Either way, in the overwhelming majority of use cases they are practically the same.
Bdw, i didn’t downvote you. I reserve it only for the most irrational fans, aka parroting fanboys.
One of the big issues with process monitoring, in the general sense, is how PID 1 checks on processes
The cgroups usage lets them make use of a very powerful Linux-specific feature. Some competitors such as Upstart tried to use ptrace for this, but that causes services to run slower
“Is a process running” I think is a harder question than you realize. systemd also offers the ability to ask “is a process running correctly” through watchdogs, and “is a process using too much memory” or “is a process using too much CPU” and offer corrective action if they are
The systemd.target issues I mention are related to different design goals. Systemd tries to start as many services as possible at once, but we need some services up within 1 second, and the rest can take longer
One option I offered was a modification to systemd so that targets could handle Before/After during our design, but the maintenance of porting it over for each update versus using OpenRC was decided to be too much effort