Что находится в каталоге etc rc3 d в linux системе

Обновлено: 06.07.2024

/etc/rc.local и /etc/init.d Программа автозапуска загрузки Linux

Использование:
1) Запуск oracle и других серверов: если вам нужно, чтобы ваш oracle запускался с системой, вы можете проверить файл / etc / oratab, а затем узнать об этом, вы Вы обнаружите, что это его правильное местоположение

2) Статическая маршрутизация: когда необходимо добавить большое количество маршрутов, которых нет в этом сегменте сети, многие люди любят добавлять аналогичные в /etc/rc.d/rc.local

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.224.0.251

route add -host 192.168.100.1 gw 10.224.0.251

В этом каталоге хранятся некоторые сценарии, обычно сценарии запуска некоторых служб, заданные при установке Linux с пакетом rpm. В системе установлено много rpm-пакетов, и в ней есть много соответствующих скриптов. Выполнение этих сценариев можно использовать для запуска, остановки и перезапуска этих служб. Например, если вы хотите перезапустить sendmail, а ваш sendmail установлен с помощью rpm, выполните /etc/rc.d/init.d/sendmail restart, чтобы запустить sendmail напрямую. Привет!
Как упоминалось ранее, сценарии в каталоге /etc/rc.d/init.d похожи на реестр в Windows и выполняются при запуске системы. Программа запускается здесь (процесс init считывает уровень выполнения), пора запустить сценарий в init.d, но он запускается не напрямую, а выборочно, потому что системе не нужно запускать все службы.
Тогда как система выбирает, что нужно активировать, а что нет? В это время вступает в силу только что упомянутый уровень выполнения. После определения уровня запуска системы сначала выполняется сценарий /etc/rc.d/rc. В исходном коде RH9 и FC7 он проверяет_runlevel (), как только он появляется (хотя реализованный код отличается, он также похож). После определения уровня выполнения для каждого уровня выполнения существует подкаталог в rc.d Это rc0.d, rc1.d… .. rc6.d. Под каждым каталогом есть ссылки на некоторые скрипты в каталоге init.d. Службы, которые должны выполняться на каждом уровне, находятся в соответствующем каталоге.Например, службы, запускаемые на уровне 5, помещаются в rc5.d, но файлы ссылок, помещенные в rc5.d, связаны с init. Соответствующий файл в d фактически работает в скрипте в init.d.

Если вы использовали систему Linux, значит, вы слышали о каталоге init.d. Для чего именно этот каталог? В конечном итоге он делает только одно, но это нетривиально, это делается для всей системы, поэтому это очень важно. Каталог init.d содержит множество сценариев запуска и остановки для различных служб системы. Он контролирует все транзакции от acpid до x11-common. Конечно, init.d - это далеко не просто. (Примечание переводчика: acpid - это новый стандарт управления питанием для операционной системы Linux; X11 также называется X Window System, а X Window System (X11 или X) - это оконная система с растровым отображением. Она присутствует в Unix и Unix-подобных операционных системах. Помимо стандартного набора инструментов и протокола для создания графического пользовательского интерфейса в OpenVMS, он может использоваться практически в существующих современных операционных системах).

Если вы используете систему Fedora, вы можете найти этот каталог: /etc/rc.d/init.d. Фактически, где бы ни был размещен init.d, он играет ту же роль.

Чтобы иметь возможность использовать сценарии в каталоге init.d, вам потребуются разрешения root или разрешения sudo. Каждый сценарий будет запускаться как команда, структура команды примерно следующая:

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

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

Я предлагаю вам познакомиться со следующими уровнями типичной загрузки Linux:

1. BIOS

BIOS отвечает за базовый ввод/вывод данных с устройств/на устройства.
Делает некоторые проверки целостности устройств. К тому же, за тестирование работоспособности электроники отвечает POST (Power-on self-test, он же «тест на адекватность себя самого», выполняющийся как этап пре-загрузки), который управляется BIOS
Ищет, загружает и выполняет программу-загрузчик ОС
Берет загрузчик из флопика, сидюка или жесткого диска. Во время загрузки BIOS'а вы можете нажать на кнопку (обычно это F12 или F2 или Del, зависит от платформы), если вам требуется внести некоторые изменения касательно настройки железа.
Как только загрузчик был обнаружен и загружен в память, BIOS передает управление ему.
Короче говоря, BIOS загружает и выполняет загрузочную запись (MBR).

2. MBR

MBR — это главная загрузочная запись, хранящаяся на жестком диске
Она размещена в 1-м секторе загрузочного диска, например /dev/hda или /dev/sda
MBR занимает меньше, чем 512 байтов. Она состоит из трех компонентов: 1) главная загрузочная информация, «живущая» в первых 446 байтах; 2) информация о таблице разделов — в следующих 64 байтах; 3) и последние 2 байта нужны для проверки корректности mbr.
Она содержит информацию о GRUB'е (или LILO).
Простыми словами — MBR загружает и выполняет загрузчик GRUB.

3. GRUB

GRUB — Grand Unified Bootloader.
Если в вашей системе установлено более, чем одно ядро, у вас есть возможность выбирать, которое из них должен выполняться
GRUB отображает ~~красивую анимацию plymouth~~ заставку, и, подождав несколько секунд интерактивного воздействия пользователя, если он не нажал ни одной клавиши, он загружает ядро, установленное по умолчанию в файле конфигурации grub.
GRUB понимает, что такое файловая система (древние загрузчики Linux'а, например, LILO этого не понимают).
Конфигурационный файл Grub обычно лежит по пути /boot/grub/grub.conf (так же /etc/grub.conf может быть символьной ссылкой на него). Вот пример файла конфигурации для CentOS:

4. Ядро или Kernel

Ядро монтирует файловую систему в соответствии с настройкой «root=» в фале grub.conf
Выполняет программу /sbin/init
Поскольку init — это первый процесс, запущенный ядром Linux, поэтому она имеет идентификатор процесса (PID) №1. Можете выполнить «ps -ef | grep init» и убедиться в этом.
initrd — это Initial RAM Disk, он же временный диск в оперативной памяти
initrd используется самим ядром в качестве временной корневой файловой системы, пока kernel не загрузится в реальную примонтированную файловую систему. Этот временный диск также содержит необходимые для загрузки драйверы, позволяющие получить доступ к разделам дисков и другому оборудованию

5. Init

Смотрит в файл /etc/inittab для того, чтобы определить уровень выполнения (run level).
Есть следующие уровни выполнения:
- 0 – прервать выполнение
- 1 – Однопользовательский режим, так называемый «Single user mode», или иными словами, консоль восстановления
- 2 – Многопользовательский режим без поддержки NFS
- 3 – Полноценный многопользовательский режим
- 4 – не используется
- 5 – X11
- 6 – перезагрузка
6. Уровень выполнения программ (Runlevel)

Вот и все. Возможно, некоторым из вас это не ново и особого интереса не было при чтении статью, поскольку она более ориентирована на начально-средний уровень знакомства з Линуксом.
В таком случае могу лишь сказать, что «повторение — мать учения» (с).

Дополнения, исправления, уточнения
В одной из прошлых тем мы разбирали структуру файловой системы Linux.
Продолжим изучать подробнее состав, начнем с директории /etc.

каталог /etc

В каталоге /etc находятся конфигурационные файлы, рассмотрим подробнее каждый из них.

/etc/rc.d

содержит основные скрипты для организации процесса загрузки;

/etc/passwd

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

/etc/fdprm

Таблица параметров флоппи-дисковода, определяющая формат записи. Устанавливается программой setfdprm.

/etc/fstab

Можем увидеть информацию о системе, какие разделы диска необходимо примонтировать при её старте.Команда mount -a (она запускается из командного файла /etc/rc.d/rc.S). Здесь также содержится информация о swaр-областях, автоматически устанавливаемых командой swapon -a.

/etc/group

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

/etc/inittab

Конфигурационный файл демона init.

/etc/issue

Файл, где содержится информация о системе с приглашением входа в систему. Параметры и возможные ключи представлены ниже, по умолчанию в файле /etc/issue/ выглядит так:

Возможные ключи файла issue:

/etc/magic

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

/etc/motd

/etc/mtab

Список файловых систем в настоящее время .

/etc/shadow

Теневая база данных пользователей. При этом информация из файла /etc/рasswd перемещается в /etc/shadow, который доступен root и включает зашифрованную информацию о паролях

/etc/login.defs

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

/etc/printcap

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

/etc/profile

файл выполняется оболочкой Bash при запуске системы, что позволяет изменять системные установки для всех пользователей.

/etc/securetty

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

Лучше оставить только tty1:

/etc/shells

Список рабочих оболочек. Команда chsh позволяет менять рабочую оболочку только на оболочки, находящиеся в этом файле. Процесс ftрd, предоставляющий работу с FTР, проверяет наличие оболочки пользователя в файле /etc/shells и не позволяет пользователю подключится к системе, пока ее имя не будет найдено в этом файле.

Приветствую всех посетителей моего родившегося блога!

В своей первой статье опишу свои первые познания в ОС Linux. Недавно поменял место работы и по служебной необходимости пришлось внедрять в свой мозг новую для себя операционную систему Linux. Ранее приходилось сталкиваться с Linux только как на рабочей станции, даже без привязки к локальной сети. Максимум до чего дошли руки - устанавливать rpm пакеты, читая пошаговый HOWTO, изъятый из просторов гугла и с использованием менеджера пакетов synaptic. При этом настройка занимала громадную уйму времени.

До настоящего времени приходилось администрировать только сети на основе просящего много денег мелкософта. Но с последними тенденциями в сфере лицензирования и обращения особого внимания органов на отсутствие заветных наклеечек на компьютерах организации, а так же желании руководства сэкономить на программном обеспечении (а что, программы продаются чтоли? О_о (с) ) пришлось "сесть собаку" на вопросах лицензий и тем самым подтолкнул себя к более глубокому изучению продуктов ОпенСорса. К тому же на новой работе стоит старенький ALT Linux Compact 3 с почтовиком qmail и pptp сервером для удаленного доступа, которых хочется скорей переустановить, ибо клиенты умирают от спама, места для почты практически не осталось + хочется какой-нибудь небольшой корпоративный Жаббер да и еще кучу пожеланий.

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

Описание 1 этапа:

Не углубляясь в кучу терминов и определений, данный этап можно описать следующими словами: BIOS из MBR (первые 512 байт диска, выбранного для загрузки) загружает First Boot Loader. FSB находит вторичный загрузчик, используя таблицу разделов, просматривая ее, обнаруживает активный раздел, после обнаружения этого раздела - загружает SSB в оперативную память и запускает его. Для корректной загрузки, активный раздел должен содержать каталог /boot, который должен находиться в начале диска и содержать Second Stage Boot Loader. В целом, SSB - это программа, которая выводит список вариантов загрузки (меню выбора загрузки операционной системы). Загрузчиком может быть LILO (более старый) или GRUB. Загрузчик берет свои настройки из конфигурационного файла (/etc/lilo.conf - для LILO и /boot/grub/grub.conf или /boot/grub/menu.lst - для GRUB). Существуют и другие версии загрузчиков, такие как syslinux, PXElinux, Isolinux, uBoot, но для наглядности, в статье я затронул только LILO и GRUB. Хочу отметить, что исторически (до появления загрузчиков LILO, GRUB и др. и когда образ ядра занимал объем не боле 1,44 Мб) данного этапа не существовало и загрузка происходила с дискеты без файловой системы, на которую был записан образ ядра Linux, который (образ) содержал в себе MBR, то есть BIOS загружал сразу образ ядра и передавал ему управление.

Описание 2 этапа:

Второй этап можно характеризовать так: подготовка системы для запуска служб демонов. При подготовке, Загрузчик загружает в память образ ядра из каталога /boot. Давайте рассмотрим пример образа ядра на примере ОС Debian 6:

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

Какой архив initrd подгружать при загрузке, так же указывается в FSB GRUB или LILO:

Описание 3 этапа:

До текущего момента процесс запуска любой UNIX системы практически не отличался. Третий этап загрузки может отличаться в зависимости от платформы, будь то Linux, BSD, MacOS и др. Я подробно рассмотрю процесс загрузки операционной системы Linux с реализацией процесса запуска с помощью пакета sysvinit (так же именуемого System V - "систем 5"). В Linux в последнее время активно внедряется разработанный "убунтологами" пакет upstart, который приходит на смену SysV, данный процесс я так же кратко опишу и немного расскажу о загрузке BSD-систем.

На третьем этапе загрузки System V происходит следующее:

Далее, процесс init согласно уровню загрузки просматривает каталог /etc/rc.d/rc0.d/ (в данном примере, цифра 0(ноль) в имени rc0.d соответствует уровню загрузки - нулевому), в котором содержатся симлинки (ссылки) на скрипты запуска системных служб, которые, в свою очередь, расположены в /etc/rc.d/init.d/ (для Red Hat) или в /etc/init.d/ (для Debian). Ссылки имеют следующий формат:

< S | K >< число >< имя_службы >, в котором: S - запуск службы (Start), K - остановка службы (Kill), < число > - число, определяющее последовательность запуска служб (00 - самая первая), < имя_службы > -имя запускаемой службы.

Уровни выполнения бывают следующие:
- 0: полная остановка машины;
- 1: single-user (однопользовательский) режим; (используется в случае серьезных проблем или для восстановления системы)
- 2: multi-user (многопользовательский) режим, без поддержки сети;
- 3: Мulti-user (многопользовательский) режим с поддержкой сети; (используется преимущественно на серверных системах)
- 4: неиспользуемый;
- 5: Мulti-user (многопользовательский) режим с поддержкой сети + графический интерфейс для входа в систему (login);
- 6: перезагрузка.
При этом, в разных дистрибутивах, возможны вариации уровней загрузки. Дистрибутив Slackware использует уровень выполнения 4 вместо 5 для полного запуска системы X Window. Debian использует один уровень выполнения для любого многопользовательского режима, обычно это уровень 2.

После запуска всех демонов, содержащихся в каталоге /etc/rc.d/rc0.d/, процесс Init запускает сценарий /etc/rc.d/rc.local (для RedHat) или /etc/rc.local (для Debian). В данном сценарии можно разместить свои настройки, которые вступят в силу после запуска всех демонов.

Далее, процесс Init запускает процесс mingetty, который запрашивает имя пользователя (о расположении mingetty, также сказано в файл /etc/inittab). После ввода имени пользователя, mingetty передает введенную информацию процессу login. Процесс login просматривает файлы /etc/passwd и /etc/shadow на наличие указанного пользователя и выводит запрос пароля. После ввода пароля пользователя, процесс login сравнивает хеш пароля с данными в файле /etc/shadow и в случае совпадения, запускает шелл.

Указанный процесс актуален для входа в текстовую консоль, при входе в графическую оболочку, вместо mingetty, процесс init запускает процесс gdm (для GNOME) или kdm (для KDE), в зависимости от того, какой оконный менеджер установлен в системе. gdm (или kdm) запускает X-сервер и выводит окно аутентификации.

После успешной аутентификации, просматривается файл конфигурации /etc/group, который определяет принадлежность пользователя к группам. А так же запускается стартовый конфигурационный сценарий /etc/X11/gdm/PreSession (для X-сервера) и конфигурационные стартовые скрипты (/etc/profile и др.) для bash, которые устанавливают настройки окружения пользователя.

Уровнем выполнения можно управлять с помощью команд.

На третьем этапе загрузки Upstart происходит следующее:

Давайте немного затронем вопрос загрузки новой системы Upstart, которая введена в действие с Ubuntu 7.10 и старше, Fedora 9, RHEL 6, планируется в Debian, . (если есть другие дистрибутивы с uppstart, буду рад комментариям об этом). Основное отличие upstart от system V в том, что работа upstart основана на обработке событий. К стати будет сказано, что одной из основных задач внедрения upstart была - уйти от последовательного запуска сервисов в SysV, тем самым ускорить загрузку ОС, сделав процесс запуска служб параллельным. Итак, система upstart при запуске, процессом init генерируется событие startup (запуск - одно из двух основных событий) - старт системы, а событие shutdown - при выключении системы. Другое ключевое событие - это ctrlaltdel, которое указывает, на то, что вы нажали клавиши Ctrl-Alt-Delete. В соответствии с событием генерируемым процессом init, обрабатываются конфигурационные фалы (*.conf) из каталога /etc/init/ (в более старых версиях upstart - каталог /etc/event.d/). В этом, собственно, и заключается вся работа upstart. Для обратной совместимости с System V существует файл /etc/init/rc.conf, который запускает демоны, согласно SysV.

Давайте рассмотрим содержимое файлов /etc/init/*.conf. Каждый из файлов должен содержать start on event (по какому (on) событию (event) осуществлять запуск (start) службы), stop on event (по какому событию останавливать запуск службы), exec либо script (что, собственно, запустить по указанному выше событию). Наиболее часто применяемые события в конфигурационных файлах - это startup, runlevel, stopped и started. startup - это событие запуска операционной системы, runlevel (с указанием уровня или нескольких уровней) - событие при смене уровня запуска, stopped - событие после остановки задания, started - событие после завершения старта задания. Просмотрев конфигурационные файлы в каталоге /etc/init/ можно найти и другие события, о которых можно почитать в man upstart-events (7). В дополнение к стандартным записям exec и script существуют записи pre-start и post-stop, реализующие выполнение подготовительных действия до выполнения exec и завершающие после завершения exec.

Данной системой загрузки также можно управлять командами.

Для отключения автоматического запуска службы в Upstart, необходимо:

На третьем этапе загрузки BSD происходит следующее:

Перед описанием 3 этапа загрузки BSD хочу отметить, что по-умолчанию на 1 этапе используется загрузчик BSD Loader, работа которого аналогична любому другому загрузчику и тоже разбита на подэтапы (загрузка FSB, SSB и т.д.). Файл конфигурации BSD Loader расположен в /boot/loader.conf. Соответственно, после запуска BSD Loader, происходит передача управления ядру и запуск процесса /sbin/init. Дальше запуск несколько отличается от Linux, т.к. в BSD нет понятия runlevel, то есть существует единый уровень исполнения. НО в BSD есть 2 режима загрузки - однопользовательский (режим восстановления) и многопользовательский.

В однопользовательском режиме загрузка происходит:
1. при выборе соответствующего пункта (Boot in single user mode) в меню начального загрузчика,
2. при задании команды boot -s в командной строке загрузчика (после выбора пункта его меню Escape to loader prompt),
3. при обнаружении серьезных (неустранимых автоматически) нарушений целостности файловой системы в ходе ее проверки на первой стадии инициализации.
При загрузке в однопользовательском режиме происходит запуск оболочки без пароля с правами суперпользователя и монтирование корневой ФС только на чтение. Запуска сценариев инициализации не происходит.

При загрузке в многопользовательском режиме, как и в Linux, выполняется 2 этап загрузки. На 3 этапе в BSD задача процесса init аналогична - это вызов и отработка сценариев инициализации, или стартовых скриптов, собранных в каталоге /etc и его подкаталогах и получение терминала (запуск процесса getty), установка его свойств и подготовка к аутентификации и авторизации (ввод логина/пароля) и последующее вытеснение getty процессом login. Отличие BSD в том, что в BSD имеет свои стартовые скрипты, отличные от Linux.

Основной стартовый скрипт -это /erc/rc, настройки применяемые по умолчанию для скрипта /etc/rc процесс init считывает, из файла /etc/defaults/rc.conf, а настройки, специфичные для текущей системы, из /etc/rc.conf, после чего осуществляется монтирование файловых систем, перечисленных в файле /etc/fstab, запуск сетевых служб, различных системных даемонов и, наконец, выполнение скриптов запуска дополнительно установленных пакаджей. Строки /etc/rc.conf имеют вид параметр="значение" (точнее service_name_enable="YES/NO"). Соответственно, service_name_enable - это имя службы, которое должно соответствовать имени скрипта запуска службы из каталога /etc/rc.d/* (/etc/rc.d/service_name_enable, например /etc/rc.d/sshd) или /usr/local/etc/rc.d/* - для ПО установленного из портов, значение yes или no соответственно включает или выключает службу.

Некоторые дополнительные системные сервисы могут быть не учтены в файле /etc/rc.conf. Тогда для их запуска нужно прописать соответствующую команду в /etc/rc.local

Не записывайте свои команды в /etc/rc.conf. Для запуска демонов, или для выполнения вашей команды во время запуска - запишите ваш скрипт в /usr/local/etc/rc.d.

Процесс остановки системы BSD

Во время контролируемого процесса остановки системы через утилиту shutdown программа init будет пытаться запустить скрипт /etc/rc.shutdown, после чего будет посылать всем процессам сигнал TERM, а затем и KILL тем процессам, которые не завершили работу.

Итого, в BSD процесс загрузки до ужоса прост - запуск скрипта /etc/rc согласно настроек /etc/rc.conf, в котором прописано, какие скрипты запуска демонов из /etc/rc.d/* необходимо запустить, а какие - нет и финалом загрузки является скрипт /etc/rc.local.

Маленький итог:

В данной статье я постарался, как можно прозрачней описать процесс запуска операционных систем UNIX, в том виде, в каком я его понял. Некоторые пособия/статьи разделяют загрузку на большее количество этапов. Я постарался изложить так, чтобы прочитав статью, можно было понять процесс загрузки UNIX не вчитываясь в кучу других материалов. Конечно, никто не запрещает углубиться в изучение процесса загрузки ОС, благо в интернете их достаточно. Жду комментариев и дополнений.

Что еще почитать:

upd 2011.01.21: переработано и дополнено описание 3 этапа загрузки
upd 2011.06.10: дополнено описание 1 и 2 этапа загрузки
upd 2011.06.12: переработка и дополнение всех этапов загрузки, добавление процесса загрузки upstart и ОС BSD.
upd 2011.06.27: Дополнение 1 и 2 этапа загрузки.

Читайте также:

Что находится в каталоге etc rc3 d в linux системе

/etc/rc.local и /etc/init.d Программа автозапуска загрузки Linux

1. BIOS

2. MBR

3. GRUB

4. Ядро или Kernel

5. Init

6. Уровень выполнения программ (Runlevel)

Дополнения, исправления, уточнения

каталог /etc

/etc/rc.d

/etc/passwd

/etc/fdprm

/etc/fstab

/etc/group

/etc/inittab

/etc/issue

/etc/magic

/etc/motd

/etc/mtab

/etc/shadow

/etc/login.defs

/etc/printcap

/etc/profile

/etc/securetty

/etc/shells

Описание 1 этапа:

Описание 2 этапа:

Описание 3 этапа:

На третьем этапе загрузки System V происходит следующее:

На третьем этапе загрузки Upstart происходит следующее:

На третьем этапе загрузки BSD происходит следующее:

Процесс остановки системы BSD

Маленький итог: