[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: default init on non-Linux platforms



On Fri, 21 Feb 2014 23:53:51 +0100
John Paul Adrian Glaubitz wrote:

> Kevin, I don't think you understand the reasoning behind this. Again,
> the problem the init system has to solve here is being able to track a
> process with a 100% accuracy, so whatever automated mechanisms you have
> configured when certain situations occur, they have to find the correct
> process to work on as to not kill the daemon instance you actually
> still need.
> 

ADRIAN, I hate it when people use your name thinking it makes any
difference to the content your about to spout.

> And, to my current knowledge, this is not possible without a mechanism
> like CGroups. Whether you rely on PID files or grep through the output
> of "ps" or use "pidof", either of them are fragile and prone to fail.
> 

Regex works just fine for me.

> I elaborated in my actual real-life case how PID files are prone to
> failure - I am aware that the situation with the full filesystem
> shouldn't occur in the first place,

Right including the rest of this email that's two counts of fantasy or
bad practice now justifying increased complexity in the kernel.

>  but, well administrators are just
> humans after all - and, using "ps" to track the process you are looking
> for to be able to restart, stop or kill it, can obviously be easily
> tricked into failure as well. 

> I was merely expressing that I think that CGroups are an indispensable
> if you're planning to use Debian to build modern productive systems with
> high availability in mind.

As I have already said in previous threads that you have obviously
forgotten from months ago. Something like CARP for complete server
redundancy or Ciscos redundancy protocol, I forget what it is called
is the way to go for many reasons.

> Just imagine some other (malicious)
> process using the same name as well or when you need to control
> different instances of the very same process.

So you keep machines that are running malicious processes online by
adding complexity to the kernel. It is people like you that meant that
kernel.org was offline for months after rediculously simple measures
weren't bothered with.

If you are lucky enough to have malicious processes that can be found
rather than a rootkit then you should be pulling the plug investigating
and hardening before all your machines take part in a DDOS.


Reply to: