Initialization - what is it? What is initialization What is system initialization.

In fact, it will not be possible to “purely” describe how the computer is initialized - in many systems this happens with slight differences, and one must take into account the set of equipment, presets, etc. But basically, it looks like this:
We turn on the power - there is a general reset of the logic and the processor, the processor begins to execute a set of instructions that are initially stored in ROM on the motherboard. The set can be logically divided into three parts:

1. Power On Self Test (POST) - runs only once and immediately after power on. This test checks the hardware for gross errors (hardware functioning in general). One of the visible steps on the screen is a memory test.
2. Initialization - runs every time the machine is rebooted (for example, when the user presses Ctrl-Alt-Del) - initializes all available devices on the board and in expansion slots (ISA, PCI, AGP).
3. The third part is the actual BIOS (BASIC INPUT / OUTPUT SYSTEM) - the basic input / output system at a low level. Some operating systems (DOS, Windows, etc.) use these functions. Usually, the entire BIOS is located on a separate chip, which is programmed at the factory, although in modern computers it can be reprogrammed directly from the system. Those. currently using Flash Memory.

The peculiarity of existing BIOSes is that they are very slow (much slower than regular RAM). Therefore, many systems simply copy the entire BIOS to RAM.

The memory test is the most visible part of the POST hardware test. By the way, about visibility - a video adapter is also equipment, and it just needs to be initialized in the first place - so that the user can see the process of testing and initializing devices. Also, you must also set the mode (refresh rate, resolution) of the screen. After all, video cards can be made by different companies, and even different models - who, if not the BIOS of the card itself, knows thoroughly how it needs to be initialized?
Each video card has its own BIOS, which is polled for its presence during hardware testing. First, the system BIOS looks for video at standard ISA VGA addresses - if there is no adapter, then it is looked for on PCI, then on AGP (or first AGP, and then PCI - this is specified in the BIOS SETUP settings). And if the video bios is found in one of the slots, then control is transferred to it.

In general, the presence of BIOS on various adapters forces the system BIOS to give them control - in the case of a video adapter, this is the inclusion of a mode, etc., in the case of a network card, booting from the network (in the case of diskless machines, remote boot from the network ) - if there is a BIOS on the network card and a hard disk, the BIOS, for example, may ask - how will we boot - from the network or from the existing HDD? If there is a SCSI adapter - it must initialize its devices (disks, CD drives, tape drives, etc.) and if there are any among the SCSI disks - it will be necessary to support int13 so that the system can access them as conventional hard drives. Although initialization of SCSI devices is optional - for example, at startup, it can be disabled - if the SCSI device is not bootable, this is reasonable.

Next, it checks for the presence of hard drives (IDE) on the I / O controller, floppy disk drives, and other similar peripherals. The keyboard is checked and after a successful check, a single beep is issued indicating that the initialization was successful (if not, the BIOS signals errors and / or reports them on the screen with a different combination of beeps).

So, briefly, it can be described as follows: everything except SCSI, IDE, USB "comes to life" immediately - the exception of adapters is the video adapter, which is initialized even before checking the memory.

Further, if there are other devices in the ISA slots that have their own ROMs (with BIOS), they are initialized at the stage of checking external devices, then PCI is checked and assigned (checking Plug and Play devices). By the way, PnP is also available on ISA adapters.
Only after that does the check for the presence of devices on the IDE bus begin.

Here the question may arise - what if there is no video adapter on ISA, but on PCI - but it "comes to life" right away - without even waiting for the entire PCI to be checked? It's just that PCI has a BIOS mapped to the usual memory space, and all PCI VGAs also have a standard VGA software part located in the same registers as if it were an ISA adapter. The system BIOS checks if there is VGA on the ISA bus - if so, then it doesn't fit on the PCI bus, if not, it scans the PCI.

Well, in the end, after initialization, the first sector of the first track of the first hard disk head is read and control is transferred to the boot sector, which already controls further actions (or a message like "NO SYSTEM TO BOOT" is issued). Or in a similar way, the system is loaded from a floppy disk.

And mixed all the cards. But who was the true pioneer?

Daniel J. Bernstein is a mathematician and cryptographer, author of the popular MTA qmail and many other lesser-known programs, daemontools being the most notable. For many modern init systems daemontools He was an example and an inspiration. I ask you inside to get acquainted with the most elegant, simple and powerful service management system in Unix / Linux.

DJB and Daemontools

Maxwell's equations for process control on Unix OS.

Attention - should not be confused daemontools written by DJB with namesake program DAEMON Tools for mounting iso images and creating virtual CD/DVD discs.

Daniel J. Bernstein created his program in 1997. The last stable release was in July 2001.

Now that the Linux community is split over systemd, it's time to remember what real init can be like in the spirit of Unix principles and philosophy. In this sense, Zen programmer DJB is the epitome of minimalism and simplicity, with Occam's razor built into his keyboard. His solutions are solid and elegant, on this foundation he builds reliable, secure software that consumes a minimum amount of OS resources. Here are some features of his style of work.

• The largest file of the multilog.c source code has only 13898, there are no strings, but bytes. The wc command only points to 617 lines of code.
• Most functions have less than 30 lines.
• The principle is never anything do not parse.
• The principle is to use everything that the OS gives and not to reinvent the wheel.

Why such strange principles, and even taking into account the fact that the author professes them fanatically? Construction material daemontools- directories, processes, FIFOs, executable files. This gives a lot of advantages in developing and debugging an application:

• Testing the start of a service is as easy as shelling pears - if the ./run executable file runs, the service will also start.
• You can use any programming language, not just Bash. Even a compiled binary will do.
• It is clear what and how the program does even without reading the documentation in detail and studying the source code.
• Parsing a variety of text structures is a surprisingly difficult task if done smartly. The author avoids this by skillfully using the hierarchical property of the Unix file system to recreate the key=value environment variable structure.

Comparison table DT

Pay attention to the unorthodox directory structure daemontools, without hesitation, the program creates directories at the root of the Unix file system. DJB added directories /service , /command to the program code and recommends creating /package for the program sources. This is considered very bad manners in Unix and Linux, and distro creators avoid it at all costs, as do root users.

Let's run through the self-praise table daemontools. Let's start with the first line. Indeed, creating and deleting a new service is as easy as shelling pears, adding or deleting a new directory in /service along with the ./run file and that's it. Compare with sysvinit and other init scripts to see how easy it is to achieve the same thing.

The second point is less convincing in the sense that, of course, it is easier when the service starts automatically for the first time, but in other systems of initialization and service management, one command is enough to start the service for the first time.

The ability to restart a terminated service automatically was a big step forward at the time. Today it is already in the order of things.

The fourth position is signals. The svc command, as shown below, allows you to send almost any POSIX standard signal to a service.

The last two positions seem somewhat contrived, it is not entirely clear how daemontools restores the state of the process unlike other inits. It is also unclear why the author considers only his program to be portable to other platforms.

DT Structure

According to the author: daemontools is a set of tools for managing UNIX services. The main differences from traditional inits (directory structures rcX.d, rc.d, rc.local, etc.) are the ability to restart the service in case of a crash and the presence of a program for maintaining and rotating logs - multilog. Also, multilog allows you to log the output of programs that cannot redirect output to syslog . Thus, it is possible to run as a service programs that are not intended for this at all.

The internals of the daemontools, with a red dotted line around the border.

Now a little about the principles of the program.

At the very beginning, the system init starts svscanboot , which then starts the svscan program in the newly created svscan directory. svscanboot then redirects the output of the running svscan to the readproctitle debug process.

core daemontools are just two programs: svscan and supervise . The first is launched with a single optional argument, and the second with a required key.

Svscan serves to start and monitor services. Every 5 seconds, Svscan checks the /service directory, unless otherwise specified, for new subdirectories. If any are found, a new copy of supervise is started for each directory.

Supervise is, as the name suggests, the controlling process. It is called with a parameter that contains the name of the directory and looks for the ./run script in it, which starts it. If for some reason ./run has ceased to be executed, then supervise will restart it after a short pause - so as not to create additional load on the OS. Supervise will not restart ./run if a ./down file is found in the directory. Supervise creates a ./supervise subdirectory in the service directory that stores process data. This data can be read using the svstat utility. The svc program is used to manage the service.

The svc command syntax and options are shown below.

• -u: Up, start the service, restart if it stops.
• -d: Down, stop the service.
• -t: Terminate, sends a TERM signal to the service.
• -k: Kill, sends a KILL signal to the service.
• -p: Pause, sends a STOP signal to the service.
• -c: Continue, sends the CONT signal to the service.
• -h: Hangup, sends a HUP signal to the service.
• -a: Alarm, sends an ALRM signal to the service.
• -h: Interrupt, sends an INT signal to the service.
• -x: Exit, supervise exits as soon as ./run or its child exits.
• -o: Once, start the service, but do not restart after it has finished.

There is another circumstance, if the supervise working directory contains a ./log subdirectory that contains ./log/run , then another copy of supervise will be started and a pipe will be created between ./run and ./log/run .

Let's try to add the sshd service.

In this case, the directory structure might look like this.

After svscan runs through this list, we get a process tree in which service processes monitor services and log.

Service Dependencies

Although the program does not maintain dependencies between different services, there is a way to achieve dependency accounting using svok for this, as follows.

• svok - checks if a specific service is running. Outputs nothing to stdout and stderr , if the service is running, then the program returns code 0, otherwise - code 100.

In this example, the python program will start only if postgres has started, if the latter has not yet risen, the script will end and then after a certain time svscan will restart it. When postgres finally comes up, python will launch the web application.

Service quoting

Using the softlimit utility, you can limit the resources provided to this service.

• softlimit - runs a program with resource limits.

Logging

If you have some program foo that doesn't log, you can easily do it with multilog , collecting stdout and stderr output with timestamps in a separate file.

After the kernel has finished booting, which we did in the last update , it's time to initialize the system. It starts by launching the init process, which is done by executing the /sbin/init file of the same name. Let's consider his regular tasks.

The first of these tasks, both in terms of execution time and value, is checking the integrity of existing file systems. To begin with, each of them is checked for the presence of a "clean unmount" bit (clean byte), which is automatically set during the correct termination of the previous session. If such a bit is found on every file system, all is well, things are moving on. If not, a forced check of an incorrectly unmounted file system is started.

It should be noted that the "clean unmount bit" by itself does not guarantee the safety of the file system and, especially, its data. It only shows that the file system was correctly unmounted in the previous session. In this case, the init process makes the reasonable assumption that its metadata and data are okay, and moves on to the next task. However, with the current use of journaled filesystems, the "clean unmount" bit is always present.

And the next task of the init process is to call and run the init scripts, or startup scripts, collected in the /etc directory and its subdirectories. These are regular shell scripts designed to be executed by the standard shell (on Linux, /bin/bash). They include sequences of commands designed to mount file systems, activate the swap area, set the system clock, start certain services and daemons, including network connections.

The commands that make up the startup scripts get their options, their values, and their arguments from special configuration files also located in /etc and its subdirectories. Configuration files (or simply configs) are either simple databases of command options and arguments, or lists of variable names (corresponding to command options used in scripts) with values ​​assigned to them. Configs are easily distinguished from scripts when viewing the /etc directory by the absence of the first bit of execution.

For example, a mandatory procedure at the stage of working out initialization scripts is to mount (and remount) the necessary file systems in read / write mode - after all, as we remember from the previous chapter, when the kernel is loaded, the root file system that carries it is mounted in read-only mode. This is done by the direct directive

# /sbin/mount -a which tells you to mount all filesystems and is part of one of the startup scripts. Which one depends on the system, and over time we will figure out where it is in our case). But what is meant by the word "everything" (the name of the -a option is from all) - that is, a list of arguments (devices and mount points), as well as options with which this or that file system should be mounted - and constitutes the contents of the configuration file /etc/fstab .

This is a very simple database, each entry corresponding to the file system to be mounted, and the fields delimited by space(s) or tabs are as follows:

• the file name of the device carrying the file system;
• mount point - a directory in the file hierarchy;
• file system type;
• mount options (often set to default).

Consistent separation of startup scripts and their configuration files is one of the cornerstone principles of system-wide configuration. In essence, during the normal course of configuration, there is practically no need for the user either to get acquainted with the contents of the scripts (although this is not harmful), or, even more so, to change anything in them (the latter is permissible only if this same user knows for sure what it does, otherwise the system can easily be brought to an inoperable state). But making changes to the values ​​of the parameters of the configuration files is not only possible, but also necessary, and, as we will soon see, in different ways. Of course, such permission does not relieve the user from understanding the meaning of their actions.

Finally, the third indispensable task of the init process is to ensure that the user logs into the system, which can also be done in various ways: in a text console or through graphical session managers.

The described initialization sequence occurs when it proceeds smoothly - if no errors occur at any of the stages. The most serious consequences will be errors in mounting filesystems, the usual source of which is an incorrect description in the /etc/fstab file (that is, elementary typos) or the lack of support in the kernel (or its module) for the type of filesystem bearing the root of the file tree. In the latter case, the kernel will panic (the so-called Kernel panic) and the continuation of the boot will be impossible.

Errors in initialization script execution usually result in the service whose startup script failed to simply not be available after the system boots.

Finally, errors in preparing for user registration are also quite unpleasant, and, as a rule, lead to the inability to start normal work.

However, there is no reason to panic in any of these cases - even when the core panics. All possible errors during system initialization are correctable in one way or another. For light flirting, including with the operating system, like a runny nose, is carried on the legs, and bed rest is necessary only in severe cases. In some situations, it is enough to complete the boot process and slightly change the settings, in others - to boot in single-user mode, in others you will have to boot from rescue media (for example, LiveCD). But surgical intervention, that is, a complete reinstallation of the system, most likely will never be required.

The reverse side of the system initialization is its stop or restart, there are practically no differences between these processes. And the shutdown command is responsible for it, which can be given on behalf of the superuser or a member of the operator group. With the -h option, it causes the machine to stop, with the -r option, it reboots it. And this command also needs an argument - the time when the stop or restart should occur. However, there is a way to instantly stop or restart:

# shutdown -h now or # shutdown -r now respectively. It is the last command that is worked out when the machine is rebooted from the keyboard by means of the "Three-Finger Salute", in the words of Patrick Volkerding.

In addition, there are also halt and reboot commands for the same purpose. However, they do not play an independent role, simply calling the shutdown command with the option to stop and restart, respectively.

The system shutdown occurs in the reverse order of its initialization. First, an attempt is made to correctly terminate all running applications, and if this is not possible, they are forcefully terminated. Then all starting services and daemons are stopped. Finally, the contents of the disk caches are written to disk and the file systems are unmounted. After that, a message will usually appear telling you that the machine can be safely powered off, or it will turn off automatically. When restarting, everything happens in exactly the same way, but after the system stops, the machine restarts automatically. The entire process of stopping and/or restarting is defined by scripts similar to the initialization scripts.

For many years, one of the first safety rules was not to stop by simply turning off the power. Indeed, until recently, this was fraught with various troubles.

However, the modern Linux kernel does support ACPI (Advanced Configuration and Power Interface) power management. It makes it possible to stop the system by simply turning off the power of the machine - by pressing the Power button on the computer case (but in no case by switching the power supply toggle switch or pulling out the power cable), the system reacts in the same way as to the shutdown -h now command. In particular, in Zenwalk, this procedure is absolutely painless. Of course, on more or less modern hardware.

To understand the system initialization process, the concept is very important. runlevels. This is one of those terms, any Russian translation of which can only confuse a novice user. Because commonly used translations like runlevels or loading levels create the impression that the system in the process of initialization sequentially goes through certain stages corresponding to them. In fact, these are sets of the same scripts that we talked about above, and which are executed in a given situation.

Calling a specific runlevel, that is, such an interconnected group of scripts, is carried out when the system is initialized by the /sbin/init program. And these groups themselves are described in its main configuration file - /etc/inittab , which describes the entire course of the init process - from checking file systems to preparing for registration.

Theoretically, the init process calls seven runlevels- from zero to six, although it seems that not all of them are involved in one distribution kit. Three of them have groups of scenarios for a specific purpose:

• 0 - halt, i.e. stop the system;
• 1 - single user mode, that is, single user mode;

After all sorts of copyrights, it first lists all the runlevels and explains their significance for the Slackware distribution, since in Zenwalk, its direct descendant, they differ only in details. So these are the details we will focus on:

• 0 = system stop;
• 1 = single user mode;
• 2 = not used, but configured similar to runlevel 3;
• 3 = multiplayer text mode;
• 4 = multi-user graphical mode with authorization through the GDM session manager;
• 5 = not used, but configured similar to runlevel 3;

id:runlevel:action:running process

Not all rows have values ​​assigned to each field.

To begin with, default runlevels are defined. In Zenwalk, unlike Slackware, the default "default" level is 4, which is described by this line:

id:4:initdefault: If it is necessary to change to boot in text mode (this can happen if the graphic system crashes), this should be replaced with the line id:3:initdefault: This is followed by a series of lines describing which scripts should be run at each of the involved runlevels and some other events like:

• system startup (performed in any case, regardless of the default runlevel);
• loading in single-user mode or switching to it from any multi-user mode;
• loading in any of the multiplayer modes;
• "three finger combinations" (Three Finger Salute, in the words of Patrick Volkrding);
• normal shutdown of the system;
• normal soft reboot;
• emergency power off;
• restoring power after a failure.

In the meantime, I will say that the transition from one runlevels to another is carried out by the command

# /sbin/init # where # is the required runlevel. For example: # /sbin/init 0 will cause the system to stop, similar to the command # shutdown -h now the command # /sbin/init 6 will reboot it, as with the command # shutdown -r now and the command # /sbin/init 1 will switch to single user mode - a situation that sometimes has to be resorted to in practice. However, this is not some kind of Zenwalk feature, but a common property of all Linux systems.

c1:1235:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux

There are six by default. Why "as if" - now we'll see: the runlevels field of all lines lists all the levels available to users, and only the first of them skips runlevel 4. But it is he who is the default in Zenwalk "e. This is due to the fact that the first virtual terminal is reserved to run the X server and session manager, so in normal life only 5 virtual terminals are available to the user.

However, since Zenwalk is focused on working in graphics mode, this is quite enough. Moreover, the number of virtual terminals can be reduced: for this, it is enough to close the corresponding lines with comments.

If necessary, no one forbids increasing the number of consoles: for this, it is enough to add the required number of lines, without forgetting to change their identifiers.

Let's also pay attention to the action field: the respawn value, which means automatic restart of the process if it ends. That is: at the end of the user session on any console, an authorization prompt immediately appears.

The last line defines the script when starting graphics mode:

X1:45:respawn:/etc/rc.d/rc.4 You can see that it is timed for levels 4 and 5, and also entails "self-respawning" at the end of the session.

On this consideration of the initialization of the system can be considered complete. If I missed something, I would be grateful for the indication of gaps. I will only add that this issue is covered in detail in Vladmir Popov's article Init et cetera or About Linux Boot Styles. The date should not confuse her - nothing fundamentally new in distributions that do not use upstart or initng has changed.

Data array initialization

To initialize an array, a "stepping" for (foreach) loop is usually used. The array is filled gradually, one element during each "run" of the loop. The for loop creates a local loop variable - to control the number of passes.

The initial value of the loop variable must match the first element of the array: A or A. The final value must match the number of array elements.

To organize the filling of a two-dimensional array with data, you need to nest one for loop in another. Thus, the operation of looping through the array column will be performed as many times as there are in the array of strings.

Initialization errors

Initialization string

Suppose we have a computer user connected to two ISPs. The connection speed varies, so the user is constantly switching manually. This is inconvenient and time consuming. Instead, it can set the initialization string on the command line:

AT+CDGCONT = 1, IP, internet.mts.ru + AT+CDGCONT = 2, IP, internet.beeline.ru.

Now the initialization string is the control process for the computer. If the MTS Internet becomes faster than Beeline, then the MTS connection is used - otherwise, the MTS changes to the Beeline connection.

The system that runs all other processes. Runs as a daemon and usually has a PID of 1. Typically (according to the Filesystem Hierarchy Standard) located at /sbin/init . There are differences in how a subsystem works in operating systems that are descended from System V and BSD-style systems.

For a long time it was the main init subsystem in Linux, until it was replaced by systemd in most distributions. Solaris 10 uses the Service Management Facility instead of init . A number of Unix systems use init alternatives: Upstart , Runit , Daemontools , Launchd , Initng , OpenRC .

During the boot process, after kernel initialization, /sbin/init is usually started as the first user-mode process, and init is responsible for booting the system further. To do this, startup scripts are launched that check and mount file systems, start the necessary daemons, configure the kernel (including loading kernel modules according to the installed hardware, configure IP addresses, routing tables and other tasks), launch the graphical shell. Basic boot information is usually placed in /etc/inittab .

The System V implementation of init uses the notion of a runlevel, the degree to which the operating system is loaded; in this case, the startup scripts for each level are arranged in directories from /etc/rc0.d to /etc/rc6.d , where the number after rc corresponds to the initialization level number.

inittab

An example /etc/inittab file:

id:5:initdefault: si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait :/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc .d/rc6 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 x:5:respawn:/etc/X11/prefdm -nodaemon

The first line describes the terminal and its default configuration. Initialization levels are described in this file first. Then the virtual consoles are initiated. The console initialization record consists of colon-separated fields and looks like this:

• 1 - serial number of the console
• 2345 - numbers of initialization levels for which the console is initialized
• respawn - this option means that init should restart the process serving the console after exiting the session or in case of a crash.
• /sbin/mingetty tty6 - program (with options) that will serve the console.

Thus, you can easily create your own init level (numbered 4 or 7, 8…) by simply editing the /etc/inittab file and creating the necessary links in the /etc/rc.d/rc*.d directory.

SysVinit

Compared to its predecessors, AT&T UNIX System III introduced a new style of system startup configuration, which was retained (with modifications) in UNIX System V and is therefore called " SysVinit ».

At any moment, the running system V is in one of the predetermined states called runlevel. At least one runlevel is the normal operating state of the system; typically, the other runlevels represent single user mode (used to recover a failed system), system shutdown, and various other states. Switching from one runlevel to another causes a set of scripts for each runlevel to run, which typically mount file systems, start or stop a daemon , start or stop the X Window System , shut down the machine, and so on.