Система инициализации. Системы инициализации Unix и Linux после SysV Инициализация системы что

И смешал все карты. Но кто же был истинным первопроходцем?

Daniel J. Bernstein математик и специалист по криптографии, автор популярного MTA qmail и множества других менее известных программ, среди которых выделяется daemontools . Для множества современных систем инициализации daemontools являлся примером и вдохновителем. Прошу внутрь для того, чтобы познакомиться с самой элегантной, простой и влиятельной системой управления службами в Unix / Linux.

DJB и Daemontools

Уравнения Максвелла для управления процессами на Unix ОС .

Внимание - не следует путать daemontools написанный DJB с программой-тезкой DAEMON Tools для монтирования iso образов и создания виртуальных CD/DVD дисков.

Daniel J. Bernstein создал свою программу в 1997 г. Последний стабильный релиз был в июле 2001 г.

Сейчас, когда в Linux сообществе наблюдается раскол из-за systemd, самое время вспомнить каким может быть настоящий инит в духе принципов и философии Unix. В этом смысле дзен-программист DJB является воплощением минимализма и простоты, а бритва Оккама у него встроена в клавиатуру. Его решения основательны и элегантны, на этом фундаменте он строит надежное, безопасное ПО, которое потребляет минимальное количество ресурсов ОС. Вот некоторые особенности его стиля работы.

• Самый большой файс исходного кода multilog.c имеет всего лишь 13898, нет не строк, а байтов. Команда wc указывает лишь на 617 строк кода.
• Большинство функций имеют меньше 30 строк.
• Принцип - никогда ничего не парсить .
• Принцип - использовать все, что дает ОС и не изобретать велосипеды.

Почему такие странные принципы, и еще с учетом того, что автор исповедует их фанатично? Строительный материал daemontools - директории, процессы, FIFO, исполняемые файлы. Это дает массу преимуществ в разработке и отладке приложения:

• Тестировать запуск службы проще простого - если запустится исполняемый файл./run , то и служба тоже запустится.
• Можно использовать любой язык программирования, не только Bash. Сгодится даже скомпилированный бинарник.
• Понятно, что и как делает программа даже без подробного прочтения документации и изучения исходного кода.
• Парсить разнообразные текстовые структуры - на удивление трудная задача , если это делать по уму. Автор избегает этого, умело используя иерархическое свойство файловой системы Unix для воссоздания структуры переменных среды ключ=значение.

Сравнительная таблица DT

Стоит обратить внимание на неортодоксальную структуру директорий daemontools , ничтоже сумняшеся программа создает каталоги в корне файловой системы Unix. DJB прописал в коде программы директории /service , /command и рекомендует создать /package для исходников программы. Это считается весьма дурным тоном в Unix и Linux, создатели дистрибутивов всеми силами избегают этого, также как и пользователи с правами root.

features	inittab	ttys	init.d	rc.local	/service
Easy service installation and removal	No	No	Yes	No	Yes
Easy first-time service startup	No	No	No	No	Yes
Reliable restarts	Yes	Yes	No	No	Yes
Easy, reliable signalling	No	No	No	No	Yes
Clean process state	Yes	Yes	No	No	Yes
Portability	No	No	No	No	Yes

Давайте пробежимся по таблице самовосхваления daemontools . Начнем с первой строчки. Действительно создание и удаление нового сервиса проще простого, добавил, или удалил новую директорию в /service вместе с файлом./run и на этом все. Сравните со скриптами sysvinit и остальных инитов, чтобы оценить простоту такого способа достичь того же самого.

Второй пункт менее убедителен в том смысле, что конечно же проще когда сервис и в первый раз стартует автоматически, но в остальных системах инициализации и управления службами достаточно одной команды для первого старта службы.

Возможность перезапустить завершившийся сервис в автоматическом режиме была на тот момент момент большим шагом вперед. На сегодняшний день это уже в порядке вещей.

Четвертая позиция - сигналы. Команда svc , как показано ниже, позволяет послать службе практически любой сигнал POSIX стандартов.

Последние две позиции кажутся несколько надуманными, не совсем понятно как daemontools восстанавливает состояние процесса в отличие от остальных инитов. Непонятно также, почему автор только свою программу считает переносимой на другие платформы.

Структура DT

По словам автора: daemontools - это набор инструментов для управления службами UNIX. Основными отличиями от традиционных инитов (структуры директорий rcX.d, rc.d, rc.local и пр.) является способность перезапустить сервис в случае его падения и наличие программы ведения и ротации логов - multilog. Также, multilog позволяет вести лог вывода программ, не умеющих перенаправлять вывод в syslog . Таким образом, можно запускать как сервис программы, для этого вовсе не предназначенные.

Внутреннее устройство daemontools, граница обведена красной прерывистой линией.

Теперь немного о принципах работы программы.

В самом начале системный инит запускает svscanboot , который затем запускает программу svscan в ново-созданной директории svscan . Далее svscanboot перенаправляет вывод запущенного svscan в отладочный процесс readproctitle .

Ядром daemontools являются всего две программы: svscan и supervise . Первая запускается с единственным аргументом по выбору, а вторая - с обязательным ключом.

Svscan служит для запуска и слежения за сервисами. Каждые 5 секунд Svscan проверяет каталог /service , если другой не задан, на наличие новых подкаталогов. Если такие будут обнаружены, запускается новая копия supervise для каждого каталога.

Supervise является, в соответствии с названием, контролирующем процессом. Он вызывается с параметром, в котором содержится имя каталога и в нем ищет скрипт./run , который и запускает. Если по каким-то причинам./run перестал исполняться, то тогда supervise его перезапустит после небольшой паузы - чтобы не создавать дополнительной нагрузки на ОС. Supervise не перезапустит./run , если в каталоге будет обнаружен файл./down . Supervise создает в каталоге сервиса подкаталог./supervise , в котором хранятся данные о процессе. Эти данные могут быть прочитаны с помощью утилиты svstat . Для управления сервисом служит программа svc .

Синтаксис команды svc и опции представлены ниже.

svc options services

• -u: Up, запустить сервис, в случае останова - перезапустить.
• -d: Down, остановить сервис.
• -t: Terminate, посылает сервису сигнал TERM.
• -k: Kill, посылает сервису сигнал KILL.
• -p: Pause, посылает сервису сигнал STOP.
• -c: Continue, посылает сервису сигнал CONT.
• -h: Hangup, посылает сервису сигнал HUP.
• -a: Alarm, посылает сервису сигнал ALRM.
• -h: Interrupt, посылает сервису сигнал INT.
• -x: Exit, supervise завершит работу как только./run или его потомок завершится.
• -o: Once, запустить сервис, но не перезапускать после его завершения.

Есть еще одно обстоятельство, если в рабочем каталоге supervise содержится подкаталог./log , в котором есть./log/run , то тогда будет запущена еще одна копия supervise и создан канал между./run и./log/run .

Попробуем добавить сервис sshd.

#!/bin/sh # перенаправить stderr в stdout exec 2>&1 # с опцией -D sshd выполняется явно, с опцией -e отладка пишется в stderr exec /usr/sbin/sshd -D -e

В таком случае структура директорий может выглядеть так.

- service/ |- ngetty/ | |- run | |- log/ | |- run |- sshd/ | |- run | |- log/ | |- run |- squid/ | |- run | |- log/ | |- run

После того, как svscan пробежится по этому списку мы получим дерево процессов, в котором процессы service следят за сервисами и логированием.

-svscan-+-service-+-ngetty | `-log-service +-service-+-sshd | `-log-service +-service-+-crond | `-log-service

Зависимости между службами

Несмотря на то, что программа не поддерживает зависимости между различными службами, есть способ добиться учета зависимостей, используя для этого svok следующим образом.

#!/bin/sh svok postgres || (echo "waiting for postgres..." && exit 1) exec 2>&1 exec python3 your-web-app.py

• svok - проверяет, запущена ли определенная служба. Ничего не выводит в stdout и stderr , если служба запущена, то тогда программа возвращает код 0, в противном случае - код 100.

В данном примере программа на python запустится только в том случае, если стартовал postgres, если же последний пока не поднялся, скрипт завершится и затем через определенно время svscan его перезапустит. Когда же postgres наконец поднимется, python запустит веб приложение.

Квотирование сервиса

С помощью утилиты softlimit можно ограничить предоставленные данному сервису ресурсы.

#!/bin/sh exec 2>&1 # сменить пользователя на foo, ограничить стек 4096 байтами, открытые # файловые дескрипторы 15 и количество процессов 1: exec setuidgid foo softlimit -n 4096 -o 15 -p 1 \ bar -n

• softlimit - запускает программу с ресурсными ограничениями.

Логирование

Если у вас есть некая программа foo , которая не ведет логов, вы без труда сделаете это с помощью multilog , собрав в отдельном файле вывод stdout и stderr с временными метками.

После завершения загрузки ядра, обеспечением которой мы занимались в прошлом update , наступает время инициализации системы. Она начинается запуском процесса init, что осуществляется исполнением одноименного файла /sbin/init . Рассмотрим его штатные задачи.

Первой из таких задач, как по времени исполнения, так и по значению, является проверка целостности наличных файловых систем. Для начала каждая из них проверяется на наличие бита "чистого размонтирования" (clean byte), который автоматически устанавливается в ходе правильного завершения предыдущего сеанса работы. Если такой бит обнаруживается на каждой файловой системе — все хорошо, дело движется дальше. Если нет — запускается принудительная проверка некорректно размонтированной файловой системы.

Следует отметить, что сам по себе "бит чистого размонтирования" отнюдь не гарантирует сохранности файловой системы и, особенно, ее данных. Он лишь показывает, что файловая система была корректно размонтирована в предыдущем сеансе. В этом случае процесс init делает не лишенное резона допущение, что с метаданными и данными ее все в порядке, и переходит к выполнению следующей задачи. Впрочем, при общепринятом ныне использовании журналируемых файловых систем бит "чистого размонтирования" присутствует всегда.

А следующая задача процесса init — это вызов и отработка сценариев инициализации, или стартовых скриптов, собранных в каталоге /etc и его подкаталогах. Это обычные сценарии оболочки, рассчитанные на исполнение стандартным шеллом (в Linux — /bin/bash). Они включают в себя последовательности команд, призванные монтировать файловые системы, активизировать область своппинга, устанавливать системные часы, запускать те или иные службы и демоны, включая сетевые соединения.

Команды, образующие стартовые сценарии, получают свои опции, их значения и аргументы из специальных файлов конфигурации, также имеющих своим местопребыванием /etc и его подкаталоги. Конфигурационные файлы (или по простому конфиги) представляют собой либо простые базы данных опций и аргументов команд, либо списки имен переменных, (соответствующих опциям команд, используемых в скриптах) с присвоенными им значениями. Конфиги от скриптов легко отличимы при просмотре каталога /etc отсутствием у первых бита исполнения.

Например, обязательная процедура на стадии отработки сценариев инициализации — монтирование (и перемонтирование) необходимых файловых систем в режиме чтения/записи — ведь, как мы помним из предыдущей главы, при загрузке ядра несущая его корневая файловая система монтируется в режиме "только для чтения". Это выполняется прямой директивой

# /sbin/mount -a предписывающей смонтировать все файловые системы, и входящей в состав одного из стартовых сценариев. В какой именно — зависит от системы, и со временем мы разберёмся, где она находится в нашем случае). А вот что понимается под словом "все" (имя опции -a — от all ) — то есть список аргументов (устройств и точек монтирования), а также опций, с которыми должна быть смонтирована та или иная файловая система, — и составляет содержание конфигурационного файла /etc/fstab .

Это — очень простая база данных, каждая запись которой соответствует подлежащей монтированию файловой системе, а поля, разделителем которых являются символы пробела (пробелов) или табуляции, следующие:

• имя файла устройства, несущего файловую систему;
• точка монтирования - каталог в файловой иерархии;
• тип файловой системы;
• опции монтирования (часто имеет значение default).

Содержимое первых двух полей каждой записи передается команде mount из стартового сценария в качестве первого и второго ее аргументов, остальных двух - как опции, обязательные (тип файловой системы) и необязательные (все прочие).

Последовательное разделение стартовых сценариев и их конфигурационных файлов - один из краеугольных принципов общесистемного конфигурирования. В сущности, пользователю при нормальном ходе настройки практически нет необходимости ни знакомиться с содержимым скриптов (хотя это и не вредно), ни, тем паче, менять в них что-либо (последнее допустимо только в том случае, если этот самый пользователь точно знает, что делает, иначе систему легко довести до неработоспособного состояния). А вот вносить изменения в значения параметров конфигурационных файлов — не только можно, но и нужно, причём, как мы скоро увидим, разными способами. Разумеется, такое разрешение не избавляет пользователя от понимания смысла своих действий.

Наконец, третья непременная задача процесса init — обеспечение регистрации пользователя в системе, каковая также может осуществляться различными способами: в текстовой консоли или через графические менеджеры сеансов.

Описанная последовательность инициализации происходит при бессбойном ее протекании — если ни на одной из стадий не происходит ошибок. Самые серьезные последствия будут иметь ошибки при монтировании файловых систем, обычный источник которых — неправильное описание в файле /etc/fstab (то есть элементарные опечатки) или отсутствие поддержки ядром (или его модулем) типа файловой системы, несущей корень файлового древа. В последнем случае ядро впадет в панику (т.н. Kernel panic) и продолжение загрузки окажется невозможным.

Ошибки при отработке скриптов инициализации обычно приводят к тому, что сервис, при выполнении сценария запуска которого произошёл сбой, просто не будет доступным после загрузки системы.

Наконец, ошибки при подготовке к регистрации пользователя также достаточно неприятны, и, как правило, приводят к невозможности начала нормальной работы.

Впрочем, оснований для паники нет ни в одном из указанных случаев — даже при впадении в панику ядра. Все возможные при инициализации системы ошибки исправимы тем или иным способом. Ибо легкий флирт, в том числе и с операционной системой, подобно насморку, переносится на ногах, и постельный режим необходим лишь в тяжелых случаях. В одних ситуациях достаточно завершить процесс загрузки и чуть изменить настройки, в других - загрузиться в однопользовательском режиме, в третьих придется грузиться с rescue-носителя (например, LiveCD). А вот хирургического вмешательства, сиречь полной переустановки системы, скорее всего, не потребуется никогда.

Оборотная сторона инициализации системы - это ее останов или рестарт, различий между этими процессами практически нет. И отвечает за него команда shutdown , которая может быть дана от лица суперпользователя или члена группы operator . С опцией -h она вызывает останов машины, с опцией -r - ее перезагрузку. И еще команде этой требуется аргумент - время, когда останов или рестарт должны произойти. Впрочем, есть способ и мгновенного останова или рестарта:

# shutdown -h now или # shutdown -r now соответственно. Именно последняя команда отрабатывается при перезагрузке машины с клавиатуры посредством "Салюта из трёх пальцев", по выражению Патрика Фолькердинга.

Кроме того, существуют также команды halt и reboot того же назначения. Однако самостоятельной роли они не играют, просто вызывая команду shutdown с опцией останова и перезагрузки, соответственно.

Останов системы происходит в порядке, обратном ее инициализации. Сначала делается попытка корректного завершения всех запущенных приложений, а при невозможности таковой — их принудительное завершение. Затем стопорятся все стартовые сервисы и демоны. Наконец, содержимое дисковых кэшей записывается на диск, и размонтируются файловые системы. После этого обычно появляется сообщение о возможности безопасного отключения питания машины или оно отключается автоматически. При рестарте все происходит точно также, но после останова системы автоматически начинается перезагрузка машины. Весь процесс останова и (или) рестарта определяется сценариями, подобными сценариям инициализации.

На протяжении многих лет одним из первых правил техники безопасности был запрет останавливать простым отключением питания. И действительно, до недавнего времени это было чревато разными неприятностями.

Однако в современном ядре Linux реализована поддержка управления питанием стандарта ACPI (Advanced Configuration and Power Interface). Она делает допустим останов системы простым отключением питания машины — на нажатие кнопки Power на корпусе компьютера (но ни в коем случае не на переключение тумблера блока питания или выдёргивание силового кабеля) система реагирует точно так же, как и на команду shutdown -h now . В частности, в Zenwalk"е эта процедура выполняется абсолютно безболезненно. Разумеется, на мало-мальски современном "железе".

Для понимания процесса инициализации системы очень важно понятие runlevels . Это один из тех терминов, любой русский перевод которого способен только сбить с толку начинающего пользователя. Потому что часто используемые переводы типа уровни запуска или уровни загрузки создают впечатление, что система в процессе инициализации последовательно проходит некие, соответствующие им, стадии. На самом деле это наборы тех самых сценариев, о которых мы говорили выше, и которые исполняются в той или иной ситуации.

Вызов определённого runlevel , то есть такой взаимосвязанной группы сценариев, осуществляется при инициализации системы программой /sbin/init. А сами эти группы описаны в главном её конфигурационном файле — /etc/inittab , описывающем весь ход процесса init — от проверки файловых систем до подготовки к регистрации.

Теоретически процесс init предусматривает вызов семи runlevels — от нулевого до шестого, хотя, кажется, ни в одном дистрибутиве они не задействуются все. За тремя из них зафиксированы группы сценариев определенного назначения:

• 0 - halt, то есть останов системы;
• 1 - single user mode, сиречь однопользовательский режим;

Использование остальных отдано на откуп создателям дистрибутивов. В чём мы сейчас и убедимся на примере нашего героя, дистрибутива Zenwalk. Для чего внимательно рассмотрим устройство его файла /etc/inittab .

В нем после всякого рода копирайтов для начала перечисляются все runlevels и поясняется их значение для дистрибутива Slackware, поскольку в Zenwalk"е, его прямом потомке, они отличаются лишь в деталях. Так что вот на этих деталях мы и заострим внимание:

• 0 = останов системы;
• 1 = однопользовательский режим;
• 2 = не используется, но сконфигурирован аналогично runlevel 3;
• 3 = многопользовательский текстовый режим;
• 4 = многопользовательский графический режим с авторизацией через менеджер сессий GDM;
• 5 = не используется, но сконфигурирован аналогично runlevel 3;

Все эти строки закрыты комментариями, то есть приводятся только для справки. А теперь начинаются строки, собственно и определяющие конфигурацию. Формат любой из строк в /etc/inittab следующий:

идентификатор:runlevel:действие:запускаемый процесс

Не во всех строках значения присвоены каждому полю.

Для начала определяется runlevels по умолчанию. В Zenwalk"е, в отличие от Slackware, "умолчальным" уровнем по умолчанию является 4-й, что описывается такой строкой:

Id:4:initdefault: Если необходимо перейти на загрузку в текстовом режиме (это может случиться при сбоях графической системы), её следует заменить строкой id:3:initdefault: Далее следует серия строк, описывающих, какие сценарии должны запускаться при каждом из задействованных runlevels и некоторых других событиях, как то:

• старте системы (выполняется в любом случае, независимо от runlevel по умолчанию);
• загрузке в однопользовательском режиме или переходе в него из любого многопользовательского;
• загрузке в любом из многопользовательских режимов;
• "комбинации из трёх пальцев" (Three Finger Salute, по выражению Патрика Фолькрдинга);
• обычном останове системы;
• обычной программной перезагрузке;
• аварийном отключении питания;
• восстановлении питания после сбоя.

Сами по себе сценарии эти мы рассмотрим в одной из последующих глав, посвящённых собственно настройке системы, тем более, что здесь менять, скорее всего, ничего не придётся.

А пока, слову скажу, что переход с одного runlevels на другой осуществляется командой

# /sbin/init # где # — требуемый runlevel. Например: # /sbin/init 0 вызовет останов системы, аналогично команде # shutdown -h now команда # /sbin/init 6 её перезагрузку, как при команде # shutdown -r now а команда # /sbin/init 1 переход в однопользовательский режим — ситуация, к которой на практике иногда приходится прибегать. Впрочем, это не какая-то особенность Zenwalk"а, а общее свойство всех Linux-систем.

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

Таковых по умолчанию как бы шесть. Почему "как бы" — сейчас увидим: в поле runlevels всех строк перечислены все доступные пользователям уровни, и лишь в первой из них пропущен runlevel 4. А ведь именно он является умолчальным в Zenwalk"е. Это вызвано тем, что первый виртуальный терминал зарезервирован для запуска X-сервера и менеджера сессий. Так что в обычной жизни пользователю доступны только 5 виртуальных терминалов.

Впрочем, поскольку Zenwalk ориентирован на работу в графическом режиме, этого вполне достаточно. Более того, число виртуальных терминалов можно и сократить: для этого достаточно закрыть комментариями соответствующие строки.

При необходимости никто не запрещает и увеличить количество консолей: для этого достаточно добавить нужное число строк, не забыв при этом сменить их идентификаторы.

Еще обратим внимание на поле действия: значение respawn, что означает автоматический перезапуск процесса в случае его завершения. То есть: по завершении сеанса пользователя на любой консоли тут же появляется приглашение в авторизации.

Последняя строка определяет сценарий при запуске графического режима:

X1:45:respawn:/etc/rc.d/rc.4 Можно видеть, что он приурочен к уровням 4 и 5, и также влечёт "самовосстановление" по завершении сеанса.

На этом рассмотрение инициализации системы можно считать законченным. Если чего упустил — буду признателен на указание пробелов. Добавлю только, что этот вопрос подробно освещён в статье Владмира Попова Init et cetera или О стилях загрузки Linux . Дата её смущать не должна — ничего принципиально нового в дистрибутивах, не использующих upstart или initng, не изменилось.

По определению «инициализация» - это подготовка программы или аппаратного устройства к работе. Эта подготовка заключается в задании начальных данных параметрам системы. Для программы инициализацией является задание значений переменным программы.

Инициализация массива данных

Инициализация массива имеет ряд подводных камней. Во-первых, в разных программных средах заполнение данных массива начинается либо с нулевого элемента A, либо с первого A, где A - название массива.

Для инициализации массива обычно используется «пошаговый» цикл for (foreach). Заполнение массива происходит постепенно, по одному элементу во время каждого «пробега» цикла. В цикле for создается локальная переменная цикла - для контроля числа проходов.

Начальное значение переменной цикла должно совпадать с первым элементом массива: A или A. Конечное - с числом элементов массива.

Для организации заполнения данными двумерного массива нужно вложить один цикл for в другой. Таким образом, операция прохода цикла по столбцу массива будет выполнена столько раз, сколько есть в массиве строк.

Ошибки инициализации

При инициализации система получает данные со всех значимых устройств, процессов или операторов. Запуск операционной системы является инициализацией данных, ведь операционная система получает отклик всех частей компьютера, включая оперативную память, жесткий диск и клавиатуру. В случае, если один из важных блоков отсутствует, ОС не сможет пройти инициализацию. Серьезной ошибкой инициализации является и известный «синий экран смерти».

Строка инициализации

Для управления инициализацией новички часто используют простые обращения (например, X = 5) или ручной выбор. Однако регулярную инициализацию нужно и можно автоматизировать.

Предположим, что имеется пользователь компьютера, подключенный к двум интернет-провайдерам. Скорость соединения меняется, поэтому пользователь постоянно переключается вручную. Это неудобно и отнимает много времени. Вместо этого он может задать строку инициализации в командной строке:

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

Теперь строка инициализации является для компьютера управляющим процессом. Если интернет МТС становится быстрее, чем «Билайн», то используется соединение МТС - в противном случае МТС меняется на соединение «Билайна».

При создании программ необходимо обладать основными терминами компьютерной терминологии. Возьмем к примеру термин инициализация. Вы знаете, что он означает? Разобраться с его значением вам поможет данная статья. Давайте разберемся, что под этим термином подразумевают профессионалы, какие виды инициализации бывают, а также разберемся с наиболее распространенными проблемами, связанными с данным процессом.

Что такое инициализация?

Данным термином сегодня называют процессы активации, создания, подготовки к работе, определения требуемых параметров для качественной и безошибочной работы приложения. Инициализация является обязательным шагом на пути приведения любой программы или устройства в состояние использования. Сам принцип действия процедуры инициализации направлен извне относительно объекта. Чаще всего под данным словом подразумевается именно процесс настройки необходимых параметров, а также задание основных правил работы, по которым будет функционировать данная программа.

Инициализация: примеры

Посмотрим, что представляет собой инициализация. Проще всего разобраться с данным вопросом будет на наглядных примерах.

1. Инициализация жесткого диска представляет собой процесс его форматирования. Сюда также может быть отнесена запись управляющей информации, вроде меток томов, описателей дорожек и прочие манипуляции.
2. Инициализация программы предусматривает задание необходимых переменных или установку программных переменных, таких как счетчики, адреса и переключатели, в нулевое значение. Устанавливается все согласно тому, что необходимо сделать для программного обеспечения данного типа. Указания по установке могут содержаться в самом файле.
3. Инициализация подсистемы печати для вывода на принтер. Данная операция подразумевает под собой следующее: необходимо перенести данные на бумаги при помощи какого-то устройства и выполнить учет всех необходимостей. Так, например, необходимо определить расширение, тип бумаги и многие другие параметры. Прежде всего на устройство подается специальный управляющий сигнал, после этого сканируются его возможности. Это делается для того, чтобы выполнить первоначальную настройку печатающего устройства и предложить пользователю соответствующий вариант, который данный тип техники может осуществить.

Рассмотрим на практике случай запуска приложений. Предположим, при запуске компьютерной игры возникает ошибка инициализации. В качестве примера рассмотрим игру Симс 3. Данное приложение сегодня пользуется большой популярностью. По каким причинам может возникнуть ошибка инициализации в данном случае? Самый распространенный вариант такой проблемы – ошибка с кодом 0x0175dcbb. Данный номер используется для того, чтобы обозначить номер ошибки, связанной с инициализацией приложения. Возникает она чаще всего из-за того, что игра конфликтует с драйверами, дополнениями и модами. От возникновения данной проблемы не застрахованы даже те пользователи, которые предпочитают использовать лицензионные игры.

Лицензия не приводит к автоматическому решению таких проблем. Что делать при возникновении ошибки инициализации? Разберемся, как можно убрать подобную ошибку. Хотя в данном случае мы будем рассматривать игру, приведенные рекомендации вполне пригодятся и при работе с более серьезными приложениями. Стоит помнить, что самой старой проблемой является использование архаических компонент программы. Прежде всего нас будут интересовать драйвера видеокарт. Их можно скачать с официального сайта компании производителя. Нелишним будет также установить NETFramework, обновленный до последней версии. Желательно данный компонент скачивать с официального сайта разработчика – компании Microsoft.

Рассмотрим наиболее популярные причины возникновения данной проблемы: это дополнительные моды, которые написаны сторонними разработчиками. В данном случае, к сожалению, придется удалить непосредственно само расширение. Если имеется информация, из-за которой вы не хотите этого делать, то можно попробовать просто переименовать папку Mods. При возникновении данной ошибки после установки можно попробовать удалить программу при помощи деинсталлятора, а затем попробовать еще раз переустановить программу. Если данная мера не поможет, то возможно поврежден диск, на котором записана игра. В этом случае единственным разумным решением будет поменять его.

Заключение

Только вам предстоит решать, что устанавливать на свой персональный компьютер. Но прежде чем добавлять на свой компьютер контент, созданный сторонними разработчиками, рекомендуется проявить особую внимательность к качеству скачиваемых вами дополнений. Возможно возникновение ошибки инициализации обновления. Как правило, возможность отката в данном случае не предусмотрена. Тогда вам придется удалять данную программу и заново ее устанавливать. Если вы решили так сделать, необходимо отдельно позаботиться о сохранности наработанной информации. Копию данных необходимо разместить в безопасном месте, например, на флэш-накопителе.

На самом деле, "чисто" описать, как компьютер инициализируется, не получится - во многих системах это происходит с небольшими отличиями, да и надо учитывать набор оборудования, предустановки и пр. Но в основном - это выглядит следующим образом:
Включаем питание - происходит общий сброс логики и процессора, процессор начинает выполнять набор инструкций, которые изначально хранятся в ПЗУ на материнской плате. Набор можно логически разбить на три части:

1. Power On Self Test (POST) - запускается только один раз и сразу после включения питания. В этом тесте проверяется аппаратура на наличие грубых ошибок (функционирование аппаратуры вообще). Одним из видимых шагов на экране - тестирование памяти.
2. Инициализация - запускается каждый раз, когда машина перегружается (например, когда пользователь нажимает Ctrl-Alt-Del) - инициализирует все доступные устройства на плате и в слотах расширения (ISA, PCI, AGP).
3. Третья часть - это собственно BIOS (BASIC INPUT/OUTPUT SYSTEM) - базовая система ввода/вывода на низком уровне. Этими функциями пользуются некоторые операционные системы (DOS, Windows и др.) Обычно, весь BIOS располагается на отдельном чипе, который программируется на заводе, хотя в современных компьютерах может быть перепрограммирован прямо из системы. Т.е. сейчас используется Flash Memory.

Особенность существующих BIOS в том, что они весьма медленны (гораздо медленнее, чем обычная оперативная память). Поэтому, многие системы просто копируют весь BIOS в оперативную память.

Тест памяти - это наиболее видимая часть теста аппаратуры на этапе POST. Кстати, о видимости - видеоадаптер - тоже аппаратура, и его как раз необходимо инициализировать в первую очередь - чтобы пользователь мог видеть процесс тестирования и инициализации устройств. Так же, необходимо установить еще и режим (частоту обновления, разрешение) экрана. Ведь видеокарты могут быть сделаны разными фирмами, да еще и разные модели - кому как не БИОСу самой карточки знать досконально, как ее нужно инициализировать?
На каждой видеокарте есть свой BIOS, который опрашивается на его наличие при тестировании аппаратуры. Сначала системный БИОС ищет видео по стандартным адресам ISA VGA, - если там нет адаптера, то он ищется на PCI , потом на AGP (или сначала AGP, а потом PCI - это прописывается в установках BIOS SETUP). И если, видеобиос найден в одном из слотов, то управление передается на него.

И вообще, присутствие БИОСа на различных адаптерах заставляет системный БИОС отдавать им управление - в случае с видеоадаптером - это включение режима и т.д., в случае с сетевой картой - загрузка с сети (в случае с без дисковыми машинами - удаленная загрузка с сети) - при наличие BIOS на сетевой карте и наличие жесткого диска БИОС, например, может спросить - как будем грузиться - с сети или с имеющегося HDD? При наличии SCSI адаптера - он должен проинициализировать свои устройства (диски, CD-приводы, ленточные накопители и т.п.) и если таковые найдутся из числа дисков SCSI - необходимо будет поддержать int13 для того, чтобы система могла обращаться к ним, как к обычным жестким дискам. Хотя, инициализация SCSI устройств необязательна - например, при старте, ее можно отключать - если SCSI устройство не является загрузочным, это разумно.

Дальше проверяется наличие жестких дисков (IDE) на контроллере ввода-вывода, дисководов для дискет и пр. подобной периферии. Проверяется клавиатура и после успешной проверки выдается одиночный звуковой сигнал, указывающий, что инициализация прошла успешно (если нет - различным сочетанием звуковых сигналов BIOS сигнализирует об ошибках и/или сообщает о них на экране).

Итак, коротко можно описать следующим образом: все, кроме SCSI, IDE, USB "оживает" сразу - из адаптеров исключение составляет видеоадаптер, который инициализируется даже до проверки памяти.

Далее - если в слотах ISA находятся другие устройства, имеющие свои ПЗУ (с BIOS) - они инициализируются на этапе проверки внешних устройств, потом проходит проверка и назначение PCI (проверка устройств Plug and Play). Кстати, PnP есть и на ISA адаптерах.
Только после этого начинается проверка наличия устройств на IDE шине.

Тут может возникнуть вопрос - а как быть, если на ISA нет видеоадаптера, а есть на PCI - но ведь он "оживает" сразу - не дожидаясь даже проверки всего PCI? Просто на PCI есть BIOS, отображаемый в обычное пространство памяти, и все VGA PCI имеют еще и стандартную VGA программную часть, находящуюся в тех же регистрах, как и в случае, если бы это был ISA адаптер. Системный BIOS проверяет, есть ли VGA на ISA шине - если да, то на PCI шину и "не лезет", если нет - то сканирует PCI.

Ну, и в конце концов, после инициализации - считывается первый сектор первой дорожки первой головки жесткого диска и управление передается загрузочному сектору, который уже управляет дальнейшими действиями (либо выдается сообщение типа "NO SYSTEM TO BOOT"). Или подобным же образом система грузится с дискеты.