Как правило, сразу после включения питания программа ПЗУ BIOS проводит тестирование оборудования, затем запускается досистемный загрузчик.

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

Загрузчик первого уровня занимает обычно не более одного сектора в самом начале диска — в его загрузочной записи. Загрузочная запись диска (Master Boot Record) — первый сектор диска, в котором хранится таблица разделов и код системного загрузчика.

Ядро операционной системы имеет довольно сложную структуру — а значит, и непростой способ загрузки; оно может быть довольно большим и может располагаться в произвольной област диска, подчиняясь законам файловой системы (например, состоять из нескольких частей, разбросанных по диску). Учесть все это первичный загрузчик не в состоянии, поэтому его задача — определить, где на диске находится загрузчик второго уровня, загрузить его в память и передать ему управление.

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

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

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

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

Этот этап специфичен для различных операционных систем. В UNIX-подобных системах при этом обычно выводится информация отладочного характера о ходе загрузке ядра.

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

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

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

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

системный плнировщик заданий — демон, запускающий определённые программы с заданными интервалами времени (подробнее см. «Служба планирования заданий»);

служба системного журнала — демон, организующий единый интерфейс для журналирования событий в системе (подробнее см. «Мониторинг и журналирование»);

служба инициализации сети — производит автоматическую настройку сетевых интерфейсов, таблицы маршрутизации и т. п. (см. «Настройка сети при загрузке системы»);

служба инициализации межсетевого экрана в Linux;

набор сетевых служб, запускающих разичные сетевые серверы (подборнее см. «Сетевые службы»);

почтовый сервер — демон, обеспечивающий отправление и доставку почты по протоколу SMTP;

служба, загружающая и инициализирующая дополнительные модули ядра;

служба, которая обычно запускается в последнюю очередь и позволяет администратору выполнять дополнительные процедуры при загрузке системы;

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

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

sendmail — один из самых распространённых почтовых серверов. Он реализует Internet-протоколы, связанные с отправлением почты (в первую очередь SMTP) как в рамках локальной машины, так и через Internet. Даже если узел не является почтовым сервером, служба sendmail служит для передачи писем между пользователями системы.

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

Демон сетевой файловой системы NFS (Network File System), которая поддерживается в большинстве UNIX-систем.

samba — это набор служб по организации сетевого файлового хранилища на основе протокола CIFS, используемого в сетевых файловых системах MS Windows. Широко применяется при взаимодействии UNIX-серверов и клиентских машин под Windows.

bind (или named) — самый распространённый сервер доменных имён для UNIX.

Главной чертой журналирования в UNIX является то, что в стандартном случае приложение не делает запись в файл журнала напрямую, а вызывает специальную системную функцию (syslog()), в качестве параметров которой передаёт как само сообщение для записи в журнал, так и сопровождающие сведения: программа-источник сообщения, время события, приоритет и характер сообщения. Список необходимых параметров функции syslog() и допустимых значений для них составляет API системных журналов, которое является частью стандартов POSIX. Использование этого API программой делает ее независимой от конкретной реализации демона ведения журнала в системе, что повышает уровень переносимости программы между разными UNIX-системами.

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

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

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

Каждая запись в системном журанале содержит следующие стандартные параметры:

Рассмотрим пример простого файла конфигурации системного журнала:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
kern.*                                                  /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;		                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  /var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

Данная конфгурация подразумевает вывод всех сообщений ядра в терминал пользователей, сообщения, связанные с почтой, сохранять в файле /var/log/maillog, связанные с аутентификацией, — в файле /var/log/secure, сообщения планировщика заданий — в файле /var/log/cron, тогда как все остальные сообщения отравлять в файл /var/log/messages.