On 06/21/2012 06:49 PM, Atte Peltomäki wrote:
> On Wed, Jun 20, 2012 at 02:42:49PM -0700, Freddie Cash wrote:
>> There's no need to do a wholesale replacement of the RC system in
>> FreeBSD to support this concept. What you are describing are "service
>> profiles". And we already have a single file that describes the
>> default "service profile" for FreeBSD: /etc/rc.conf. That lists
>> every service that should be started (or stopped).
>> All that's missing is a way to tell the RC system to use a different
>> rc.conf file (like rc.conf.mobile, or rc.conf.wireless or
>> rc.conf.whatever), and to run through the RC setup based on that file.
>> Our current RC system does everything needed except:
>> - parallel execution of items that don't depend on each other
OpenRC does this.
>> - monitor running services and restart them if they crash
OpenRC does not do monitoring, but it has the prerequisites in place
necessary to implement that. It will tell you which services crashed if
you run `rc-status`. It should be possible to implement
> - Service dependencies: if a service fails that is required by another
> service, the other is stopped as well.
It is possible to implement this in OpenRC.
> - Monitoring services and ability to configure the service supervisor
> behaviour: if service fails and is restarted X times in period Y,
> execute action Z.
This is also possible to implement, although it would be a pain.
> - Extending the concept of service beyond userland. Kernel services are
> services too, if eg. network is down, you probably don't want to even
> try to start a dozen jails.
OpenRC does this.
> - Permission control (like possible in jails now, "limited root"),
> non-root users can be delegated permissions to start/stop selected
> services and configure their behaviour.
This description is too vague for me to be able to comment on it.
> It's clearly arguable as to which of these features and to what extent
> is reasonable to implement and whether or not it can or should be done
> in the existing rc system, instead of implementing a new one that just
> supports the old rc system as it is.
> There are real benefits in some of these features, but they can easily
> turn out as esoteric features in a bloated piece of code, if not
> implemented with great care. I don't know the internals of current rc
> system well enough to form educated opinion on how any of this could be
> done in practice, but I have plentyful experience in how and why projects
> fail and in this particular case I see a lot of chances for fail with
> relatively little gain.
> Just something to think about.. Might be worth noting that I work with
> Linux systems most of the time and over-engineering is a chronic problem
> there. I've always admired the simple but effective BSD approach, rather
> do less but well than a lot badly.
OpenRC is about 10,000 lines of code and is a mix of C and POSIX shell.
Performance critical code is written in C. Debian's sysvinit is 3,000
lines of bash. POSIX shell is more verbose than bash and C is even more
verbose than POSIX shell, but I would consider it to be fairly lean.