Operation Manual

The blogd daemon is a service started by boot and rc before any other one. It is

stopped after the actions triggered by these scripts (running a number of subscripts,

for example, making block special les available) are completed. blogd writes any

screen output to the log le /var/log/boot.msg, but only if and when /var

is mounted read-write. Otherwise, blogd buffers all screen data until /var becomes

available. Get further information about blogd on the blogd(8) man page.

The boot script is also responsible for starting all the scripts in /etc/init.d/

boot.d with names that start with S. There, the le systems are checked and loop

devices are congured if needed. The system time is also set. If an error occurs

while automatically checking and repairing the le system, the system administrator

can intervene after rst entering the root password. The last executed script is

boot.local.

boot.local

Here, enter additional commands to execute at boot before changing into a runlevel.

It can be compared to AUTOEXEC.BAT on DOS systems.

halt

This script is only executed while changing into runlevel 0 or 6. Here, it is executed

either as halt or as reboot. Whether the system shuts down or reboots depends

on how halt is called. If special commands are needed during the shutdown, add

these to the halt.local script.

This script calls the appropriate stop scripts of the current runlevel and the start

scripts of the newly selected runlevel. Like the /etc/init.d/boot script, this

script is called from /etc/inittab with the desired runlevel as parameter.

You can create your own scripts and easily integrate them into the scheme described

above. For instructions about formatting, naming and organizing custom scripts, refer

to the specications of the LSB and to the man pages of init, init.d, chkconfig,

and insserv. Additionally consult the man pages of startproc and killproc.

WARNING: Faulty init Scripts May Halt Your System

Faulty init scripts may hang your machine up. Edit such scripts with great care

and, if possible, subject them to heavy testing in the multiuser environment.

236 Reference