Re: Question about Facility names
initscriptsNG
-------------
This is a proposal for modifications in the SystemV initscripts that
implements dependencies but retains compatibility with SystemV packages.
I began to work in it some time before I knew about Richard Gooch's
approach, but I decided to finish it because my aimings were somewhat
different:
* Backward compatibility: old, SystemV-compliant packages installed in a
iniscriptsNG system will still work.
* Forward compatibility: new packages (prepared to work with initscriptsNG)
will also work if installed in an older, SystemV system.
* The "runlevel" notion is kept entirely.
IMPLEMENTATION DETAILS
* The directory hierarchy remains the same, i.e. the script files stay
int /etc(/rc.d)?/init.d, there are directories for each runleevel
(/etc/rc.d/rc<n>.d) and so on.
* Most initscripts' scripts are kept untouched.
* All initscriptsNG compliant service scripts (in /etc/rc.d/init.d)
have an additional "comment" line, as in the example:
# needs: network
Scripts that does not depend on any other service still have that
line, so this script can be identified as initscriptsNG compliant:
# needs:
* In each runlevel directory (/etc/rc.d/rc<n>.d) the legacy
(SystemV) scripts continue to follow the [SK][0-9]{2}name symlink
convention.
* Each initscriptsNG-compliant script will appear in the runlevel
directory ONLY IF that service is needed in that runlevel.
Also, the script will appear in the runlevel directory with its
own name. For example, if the /etc/rc.d/init.d/smb service needs
to be started in runlevel 3, there will be a file called
/etc/rc.d/rc3.d/smb. This file can be a symlink or a regular file;
it is not opened itself.
* In the /etc/rc.d/rc script, the /etc/rc.d/rc<n>.d/K* scripts are
called first.
Then a special C program (by now, its name is "initservices") will
scan /etc/rc.d/rc<n>.d directory to see which services need to be
started for that runlevel.
The directory /var/lock/subsys is scanned to be which services are
already running; that services are not started again. The services
not needed in the current runlevel will be stopped.
(Scanning /var/lock/subsys can sound dirty, but it will catch even
the services that the system administrator had started by hand.)
Of course, all these operations are done taking dependences in
account, for starting AND stopping of services.
* Finally, the /etc/rc.d/rc<n>.d/S* legacy scripts are started.
This scheme allows for an administrator to migrate smoothly from a
legacy, pure SystemV system to a initscriptsNG system, since:
- A initscriptsNG script can depend on legacy services, since
initservices always calls /etc/rc.d/init.d/<script>.
- The legacy services ([SK]*) will still be started/stopped,
even though it will slow down the process a bit.
In a legacy-free system, the /etc/rc.d/rc<n>.d directories will
have only the names of the services that are needed for that
runlevel. For example:
# ls -1 /etc/rc.d/rc3.d
local
netfs
random
smb
sshd
SPECIAL FLAGS FOR "needs: "
# needs: $ipsec
The dollar sign points to a "soft" dependency. For example, if ipsec
is explicitely initialized in the runlevel, the service that contains
the above line is guaranteed to be started after ipsec (and stopped
before "ipsec stop".)
But, if the IPsec service is not explicitely required in the runlevel,
the soft dependency will be ignored.
# needs: %last
The percent sign is for special symbols. The only special symbol defined
in the current implementation is 'last'. This symbol will schedule the
script to be run after all others.
Of course, '%last' has lower priority than dependencies. If the dependency
tree forces a service to be started earlier, '%last' is ignored. Also, if
two or more services request '%last', that scripts will be run after all
others, but the order WITHIN '%last' scripts will be random.
GHOST OR VIRTUAL SERVICES
Ghost services or virtual services are a logical aglutination of services
created to simplify the dependency tree. In the current implementation
of initscriptsNG, there is just one ghost service: network-base,
that has itself the following dependencies:
# needs: $pcmcia $adsl-init network $ipsec $cipe
(ipsec and cipe service scripts shall themselves depend on 'network')
So, all the services that depends on network system will just specify
# needs: network-base
instead of all that dependencies (pcmcia, adsl-init etc. etc.)
MODIFIED VERSIONS OF ntsysv AND chkconfig
Since we want SystemV compatibility, it is desirable that the user continues
to use the same utilities. The current implementation of initscriptsNG offers
patches to ntsysv and chkconfig. That utilities become able to identify if
the service script is legacy or not, and will behave accordingly.
MULTITHREADING AND SPEED
The current implementation of "initservices" does multithreading safely.
That program accepts 3 parameters:
/sbin/initservices <runlevel> <threads> <debug?>
The <runlevel> parameter is required. The default number of threads is one.
If a third parameter is present (it does NOT matter what it is), the debug
mode is enabled.
Systems that want to use multithreaded boot will need to change the
service scripts. Redhat-style scripts print an [ OK ] or [ FAILED ], and
it is not useful in multithreaded boot since the cursor will probaby in
in a different line. A good compromise would be to print a new line
with something like "service xyz FAILED" only if there was some problem.
I guess the biggest speed increaser in this scheme (in a 100% initscriptsNG
compliant system) is the elimination of all that K* scripts, that are run
even if the service is not started in any runlevel. I did not make extensive
tests to determine if multithreading increases the boot speed.
INITSERVICES DEPENDENCY TREE
Probably the initservices dependency tree algorithms are not the best (they
use recursion extensively), but they work well for the task it is aimed to.
CURRENT VERSION OF initscriptsNG & friends
Everything discussed here can be found at
http://bazar.conectiva.com.br/~epx/initscriptsNG
I have been using this modified version of initscripts in 2 machines of mine
(one of them is a notebook)
Reply to: