FCNewInit

From FedoraProject

Jump to: navigation, search

Contents

Fedora New Init System

The following is a analysis of alternative init systems and why Fedora is planning on extending the existing system based on dbus.

Development

Development will take place in the initscripts CVS repository. 

$ unset CVS_RSH
$ export CVSROOT=:pserver:anonymous rhlinux.redhat.com:/usr/local/CVS
$ cvs -z3 login
$ cvs co initscripts

Existing Sys V based implementation

Please refer to any of the varied references on the net for System V init to get a general idea of how the current init system works.

The current initialization and bootup system has generated various complaints:

Over time, various alternative frameworks have popped up, including, but not limited to:

Looking at how these stack up:

A lot of these claim "look how much faster we boot!". However, in most cases they miss the point. For example:

  1. The new-fangled init system has:
    1. exec nscd
  2. The current init system has:
    1. make sure nscd directories are in place
    2. check to make sure it's not already running
    3. set ulimits correctly
    4. set nice level
    5. setuid to a specified user, if necessary
    6. exec nscd
    7. log whether or not it succeeded

Telling me that A. is faster is meaningless, and, frankly, not useful. What's needed is to make B. faster. In some cases, this can mean eliminating some of those steps. But blindly eliminating all of them is silly.

The other aspect of bootup speed is parallelization. Initially, this seems like a big win. However, testing of simple naive implementations show that, at least initially, parallelization isn't a huge benefit. Generally, this is because disk seek time and other I/O limitations can dominate. Moreover, a not insignificant portion of boot time is the parts handled by /etc/rc.sysinit; this is almost entirely linear in nature (need to load modules first, then check filesystems, then clean out /tmp, etc.)

Currently, LSB support is wedged in via chkconfig. chkconfig can parse LSB standard headers for start and stop levels. For LSB dependencies, a conversion to the current Sxx/Kxx priorities is done at script installation time by computing a valid start priority relative to the dependencies specified.

This does have some problems: - priorities aren't recomputed if other dependencies are added/changed - adoption of other LSB features is slow

Moreover, very few of the current initscripts correspond to LSB standards such as for exit codes - in fact, they're very much ad-hoc in that regard.

Services can be queried individually for status, and there's a global view of what services are configured to start via system-config-services. There's no combination of this, however. (And, the implementation of system-config-services leaves much to be desired.)

Some of the newer implementations actually do handle this.

Earlier (prior to FC4) initlog was used. This was a inefficient and badly coded (by me!) program that basically dumped a program's output to syslog if it failed, and otherwise logged a simple '<foo> succeeded'. However, this only happened on startup; there was no monitoring of services to see if they failed later, or respawning of services if they did fail. Moreover, since it was just logging program output, it didn't log in a way that could be easily monitored or picked out.

So, how to solve these problems?

Switch to alternative systems or extend the existing one. This would include, at a minimum, /etc/rc. It may also include /sbin/init, and could extend to crond, atd, xinetd, and other service frameworks as well.

Features required by this implementation:

The services should also post notifications via D-BUS when they've started successfully, and (more importantly) when they haven't, or when they've unexpectedly exited.

This should handle most of the concerns above. More speed hopefully will fall out of this, but if it doesn't, oh well.

Looking at these features, the best way to do this is almost certainly to add the D-BUS, etc support into the services themselves, and provide a wrapper for legacy LSB and other initscripts that provides the D-BUS interface to them.


Steps to solve these problems

  1. Clean up all initscripts
  2. Clean up /etc/init.d/functions
  3. Replace /etc/rc
  4. Make gdm/prefdm an initscript with early login
  5. D-Bus support

Backwards compatibility and choice of solution

After reviewing most of the projects mentioned below it became clear that the amount of work needed to put into them to solve the problems we're facing at the moment surpased the work we would need to put into the existing system to extend it to what we needed. So instead of jumping onto one of the new projects which, all in their own way make a lot of sense and solve different problems we decided to extend the current system following the KISS principle: Keep it Simple, Stupid. The major points are:

Alternative options

Things to look at when implementing this:

http://www.initng.org/

Package available in Fedora Extras. The package maintainer is fixing problems upstream as well. A GUI is also available as rpm , although not in any repository yet.

http://www.tildeslash.com/monit/index.php

Looks interesting and has a compatible license. Someone more knowledgeable on the subject should investigate this - Rahul

http://www.gnome.org/~seth/blog/2003/Sep/27

Beat code out of Seth if necessary.  :) He's got the right idea, even if I quibble with some of his implementation. (Not sure that python is a good idea here, at least for parts of it.)

http://www.macgeekery.com/tips/all_about_launchd_items_and_how_to_make_one_yourself http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/launchd.8.html http://arstechnica.com/reviews/os/macosx-10.4.ars/5

http://www.pardus.org.tr/eng/projeler/comar/SpeedingUpLinuxWithPardus.html

One major Python script is called, this one starts the other, in Pyhton re-written scripts. The scripts are improved I/O wise (also with the advantages of Python vs shell script) but are also parallelized.

http://smarden.org/runit/

Two modes of operation: run hand in hand with SysV init or replace init completely. Provides the tools that enable service supervision, parallel startup and per service logging. Documentation on the tools is detailed but implementation schemes are poorly documented. Can be compiled with dietlibc to produce very, very small executables with tiny memory footprints. The current init scripts can be used as runit scripts with trivial changes (using the services own/internal option to run in the foreground instead of forking into the background). Requires some upstream work to get (a few) service developers to provide the foreground option that does not produce extra debug output. runit extends the ideas developed in deamontools (and monit?). Compiles and runs on Linux, *BSD, MacOSX and Solaris. runit has been kicking around since 2000 and is quite stable and mature. It is used as the default init scheme on two distros: Annvix and Zinix. Most importantly it meets close to 80% of the requirements listed above and can do 100% with a bit of glue logic layered around it (especially with regards to dependancies and oneshot (non-daemon) scripts). Initial testing shows a 50%-60% boot speedup on average running everything installed on a default Fedora 8 DVD install (everything selected). Oddly enough runit can also be used with Upstart as well as Init.


Things we'd like to look at, but can't (GPL License incompatability) :

http://docs.sun.com/app/docs/doc/817-1985/6mhm8o5n0?a=view http://www.filibeto.org/aduritz/truetrue/solaris10/sol-smf.pdf http://mediacast.sun.com/share/lianep/t-smf-general-march-2005.pdf

You can look at the docs. You can probably even play with a OS X and Solaris 10 implementation.

You can not look at the code.

Required languages of implementation: C, potentially a little python

Not much flexibility here. Obviously, the lower level in the bootup process you get, the more you're confined to C.

See also

[[Navigation(children)]

Retrieved from "https://fedoraproject.org/wiki/FCNewInit"