Re: default init on non-Linux platforms
On 02/21/2014 01:00 PM, heroxbd@gentoo.org wrote:
>> So, OpenRC actually also relies on files - like System V Init - to
>> track the state of a service? Isn't that approach somewhat unreliable
>> and hacky?
>
> I bet you are going to tell me the only reliable and non-hacky way to
> track the state of a service is not forking/writing to files but
> starting it foreground by a long-living daemon. I agree with you.
Well, I was thinking about something like CGroups. I don't like the
idea of having to rely on files for an init system to be able to
track the processes it has started.
I agree and understand that this was the way to go back in the old
days, but we shouldn't be using that on current setups.
At my department, we stumbled right over this design when the /var
filesystem was full and System V Init could no longer create PID
files to be able to track services, yet it started services without
complaining.
Since we had to restart our dhcpd several days on a particular day,
System V Init was unable to track whether the daemon was already
running and we ended up with several dozen instances.
Sure, it's probably a bug in the init script used as it didn't
check for enough disk space and wasn't failing when the disk is full.
But again, this is a core component depending on external scripts
being bug free which is not the correct approach when you are
aiming for something robust.
> OpenRC leverages cgroups when available. We are also working on a plugin
> framework for external supervisors such as djbtools, runit and s6 (maybe
> launchd, smf, systemd, ... as well if they're hackable) to do this
> foreground status tracking while integrated with OpenRC: We are not
> there yet though.
Can external supervisors like djbtools or runit actually reliably track
processes and if, yes, how? From my understanding, it's impossible
to be able to really track a process once it has started when
you don't have the possibility to use something like CGroups as
services could always just double-fork. The tracking has to be
done through a mechanism provided by the kernel, doesn't it?
And grepping through the output of "ps" or similar is not what
I would consider reliable and robust either.
> These advanced features are optional. We can still use the unreliable
> and hacky way of trakcing files when the task is trivial, like a
> personal VPS or laptop which do not care much about running sshd/httpd
> for 3 years non-stop.
Sure, I fully agree. But there are actually many enterprises who
need something with 99% service availability. Our department
runs a webserver, a login node for 1200 users and a large compute
clusters with over 200 nodes and an SGI UV1000 (1024 CPUs, 2 TiB),
so we need something which is able to control resources and track
processes. Many enterprises and websites run Debian.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: