Replacing rc(8) (Was: FreeBSD Boot Times)

[Mike Meyer]

On Thu, 21 Jun 2012 12:22:08 +0200 (CEST)
Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl> wrote:

> Lets make a summary.
> 
> What functionality would be good to have in FreeBSD that doesn't exist:
> 
> 1) "runlevels" with arbitrary names. runlevel change would start and stop 
> right services.

With a couple of additions:
     - it should be easy to see which services are on at a given runlevel.
     - it should be easy to see which runlevels a service is on at.

> 2) exploit startup parallelism.
> 
> 
> What we do not want to change:
> 
> - file structure which is simple. one file in rc.d/ per service and one 
> global config file (rc.conf)
> - anything else that would make things more complicated.
> 
> 
> As for
> 
> 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or runlevel 
> list for each service or runlevel exclusion list for service.
> 
> 
> examples:
> 
> service1_enable="YES"
> service2_enable="NO"
> service3_enable="foolevel maintenance"
> service4_enable="YES -foolevel" (or ALL -funkyrunlevel)

Using two symbols to indicate negation - one to start, and then one on
each runlevel - is overkill. There's not a use case where you have a
keyword YES or ALL and then runlevels that you start. Personally, I'd
restrict YES/NO/ALL to being single symbols, and use "NOT runlevels"
to mean "All but these". A bare "NOT" should get the same treatment as
a YES/NO/ALL with text after it.

> name of default runlevel may be "full" or "multiuser"
> 
> service 1 will always work, service 2 never, service 3 only at runlevels 
> "foolevel" and "maintenance", service4 with any runlevel except 
> "foolevel".
> 
> still single rc.conf, not much bigger in practice.

But each line has become more complicated, going from a simple on/off
setting to a small language that can even have errors (like "foolevel
-barlevel"). This violates the second thing on your list of things we
don't want to change. Further, while you can easily tell what
runlevels a service is on at, you can't easily tell what services are
on at a given runlevel - that begs for a tool to be written.

If you instead violate the requirement that we stick with a single
rc.conf, the conf files can continue to have the same contents. For
instance, create rc.conf.d/<runlevel>. If rc.conf exists, we just
ignore the directory. Otherwise, use rc.conf/<runlevel>. Or maybe
rc.conf gets is a link to rc.conf/default.

The downside is that it adding a service now becomes harder - you have
to edit each runlevel script instead of just one. This also begs for a
tool to be written. Given the choice between having a file that wants
a tool for reading, or one that wants a tool for writing, I'll take
the latter.

> 2) no change in rc.d/* scripts and rc.conf, but change in scripts.

That's also true for my proposal.

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org