Опубликован: 18.04.2021 | Доступ: свободный | Студентов: 1022 / 535 | Длительность: 04:36:00
Лекция 2:

Linux

< Лекция 1 || Лекция 2: 123456 || Лекция 3 >
Ядро системы

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

В зависимости от назначения системы, меняется и список демонов которые должны быть в работе. Также для управления демонами во время работы должна быть какая-то система по контролю за ними.

Службы могут управляться shell скриптами или корневым демоном управляющим всеми остальными демонами. Первый метод реализуется стандартом SysVinit, также известным как System V или просто SysV, но он устарел и практически больше не используется. Второй способ реализуется с помощью systemd и Upstart (который тоже устарел). Условно говоря, диспетчер служб - это первая программа, запускаемая ядром в процессе загрузки, поэтому ее PID (идентификационный номер процесса) всегда равен 1.

SysVinit

Для понимания, всё же рассмотрим старую версию инициализации в стиле SysV. Диспетчер служб, основанный на стандарте SysVinit, будет предоставлять предопределенные наборы состояний системы которые называются runlevels (или уровни исполнения/уровни работы ОС), и соответствующие им файлы shell script'ов для выполнения. Уровни исполнения существуют от 0-го до 6-го.

Runlevel 0 - Выключение операционной системы.

Runlevel 1, s or single - Перевести систему в режим системного администрирования. При этом все локальные файловые системы смонтированы. Работает только небольшой набор существенных процессов ядра. Этот режим предназначен для решения административных задач, например, установки дополнительных пакетов. Все файлы доступны, и никакие пользователи в системе не зарегистрированы. Используется для диагностики/обслуживание и восстановления системы.

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

Runlevel 3 -Расширить многопользовательский режим, предоставляя доступ по сети к локальным ресурсам.

Runlevel 4 - Multi-user mode. - Можно определять как альтернативную конфигурацию многопользовательской среды. Этот уровень выполнения не обязателен для работы системы и обычно не используется.

Уровни 2 и 4 не используются.

Runlevel 5 - Multi-user mode. Такой же как и третий, но присутствует также графическая оболочка.

Runlevel 6 - Перезагрузка системы. Остановить операционную систему и перезагрузить ее в состояние, задаваемое записью initdefault в файле /etc/inittab.

За управление runlevels и связанными демонами и ресурсами отвечает программа /sbin/init. Во время инициализации системы программа init определяет требуемый уровень запуска, загружая его из файла /etc/inittab, и загружает связанные сценарии, перечисленные там для данного уровня запуска. Каждый уровень запуска может иметь множество связанных конфигурационных файлов, обычно сценариев которые находятся в каталоге /etc/init.d/. Поскольку не все уровни выполнения в разных дистрибутивах Linux одинаковы, описание уровней выполнения конкретной операционной системы можно просмотреть собственно в самом дистрибутиве.

Синтаксис /etc/inittab:

id:runlevels:action:process

Где id - обобщённое название состоящее из 4х букв, runlevels - список уровней для которых действие выполняется, action - само действие и process - что будет исполнено.

Доступные действия:

boot - процесс будет выполнен во время инициализации системы, runlevels в данном случае игнорируется.

bootwait - процесс будет выполнен во время инициализации системы и init процесс дождётся окончания выполнения данного процесса, runlevels в данном случае игнорируется.

sysinit - процесс будет выполнен после инициализации системы, runlevels игнорируется.

wait - процесс будет выполнен для указанного runlevel. Init процесс будет ожидать завершения его инициализации для продолжения.

respawn - процесс будет перезапущен, если он отключится.

ctrlaltdel - процесс будет выполнен по сигналу SIGINT, который вызывается сочетанием клавиш Ctrl+alt+Del

Стандартный runlevel будет выбран если вы не указали ваш собственный. Он тоже указывается в файле /etc/inittab, с конфигурационной строкой id:x:initdefault.

Пример как выглядит /etc/inittab:

'# Default runlevel
id:3:initdefault:
# Configuration script executed during boot
si::sysinit:/etc/init.d/rcS
# Action taken on runlevel S (single user)
~:S:wait:/sbin/sulogin
# Configuration for each execution level
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Action taken upon ctrl+alt+del keystroke
ca::ctrlaltdel:/sbin/shutdown -r now
# Enable consoles for runlevels 2 and 3
1:23:respawn:/sbin/getty tty1 VC linux
2:23:respawn:/sbin/getty tty2 VC linux
3:23:respawn:/sbin/getty tty3 VC linux
4:23:respawn:/sbin/getty tty4 VC linux'

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

Сценарии, используемые init для настройки каждого уровня выполнения, хранятся в каталоге /etc/init.d/. Каждый уровень запуска имеет связанный каталог в /etc/ с именем /etc/rc0.d/, /etc/rc1.d/ или /etc/rc2.d/ и т. д. со сценарием, который должен выполняться в соответствии с начинающимся уровнем запуска.

Поскольку один и тот же сценарий может использоваться на разных уровнях выполнения, файлы в этих каталогах представляют собой просто символические ссылки (softlink) на фактические сценарии в /etc/init.d/. Кроме того, первая буква имени файла ссылки в каталоге уровня запуска указывает, следует ли запускать или прекращать службу для соответствующего уровня запуска. Имя файла ссылки, начинающееся с буквы K, определяет, что служба будет завершена при переходе на уровень выполнения (kill). Начиная с буквы S, служба будет запускаться при выходе на уровень запуска (start). В каталоге /etc/rc1.d/, например, будет много ссылок на сетевые сценарии, начинающиеся с буквы K, учитывая, что уровень выполнения 1 - это уровень запуска для одного пользователя без подключения к сети.

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

$ runlevel
N 3

Команда в выводе даёт два значения. Первое из них - это предыдущий уровень исполнения, а второе - текущий.

Для перехода между различными уровнями исполнения, можно использовать команду telinit в синтаксисе telinit $runlevel.

systemd

В текущий момент основная система менеджмента ресурсов и сервисов это systemd. Единица для systemd это unit. Он включается в себя имя, тип и конфигурационный файл.

Типы systemd unit-ов:

  • service - самый распространённый тип, используется для активных процессов в системе. Может быть инициализирован, остановлен и перезапущен (на самом деле больше действий, хотя они подразумевают комбинации из этих трёх)
  • socket - Тип socket используется для сокетов в файловой системе или сетевых сокетов. Для существования socket'a необходим также сервис, который запускается параллельно и принимает сообщения через этот сокет.
  • device - unit который связан с аппаратным устройством которое было идентифицировано ядром. Устройство будет считаться unit'ом systemd только в случае наличия udev правила. Device unit используется для разрешения зависимостей конфигурации при обнаружении оборудования (то есть добавления и конфигурации необходимых модулей ядра)
  • mount - точка монтирования в файловой системе, аналогично точкам монтирования в файле /etc/fstab
  • automount - Тоже самое что и mount, но будет смонтирован автоматически как только кто-то попытается зайти в точку монтирования
  • target - группа юнитов других типов, для того чтобы оперировать ими как одним
  • snapshot - сохранение состояния менеджера systemd (не везде доступно)

Для управления юнитами systemd используется команда systemctl.

  • systemctl start unit.service - запускается сервис
  • systemctl stop unit.service - останавливает сервис
  • systemctl restart unit.service - перезапуск сервиса
  • systemctl status unit.service - статус сервиса
  • systemctl is-active unit.service - проверяет состояние сервиса
  • systemctl enable unit.service - автозапуск сервиса
  • systemctl disable unit.service - отключение автозапуска сервиса
  • systemctl is-enabled unit.service - проверка статуса автозапуска сервиса
  • systemctl mask unit.service - маскирование сервиса
  • systemctl unmask unit.service - снять маскирование сервиса

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

Команда systemctl также может управлять системными целями. Например, модуль multi-user.target объединяет все модули, необходимые для многопользовательской системной среды. Он схож с уровнем выполнения 3 в системе построенной на SysV.

Команда systemctl isolate чередует разные цели. Итак, чтобы вручную изменить целевой многопользовательский режим:

# systemctl isolate multi-user.target

Существуют соответствующие цели для уровней запуска SysV, начиная с runlevel0.target и заканчивая runlevel6.target. Однако systemd не использует файл /etc/inittab. Чтобы изменить системную цель по умолчанию, в список параметров ядра можно добавить параметр systemd.unit. К примеру, чтобы использовать multi-user.target в качестве стандартной цели, параметр ядра должен иметь вид systemd.unit = multi-user.target. Все параметры ядра можно сделать постоянными, изменив конфигурацию загрузчика.

Другой способ изменить цель по умолчанию - изменить символическую ссылку /etc/systemd/system/default.target, чтобы она указывала на желаемую цель. Переопределение ссылки может быть выполнено самой командой systemctl:

# systemctl set-default multi-user.target

Точно так же вы можете определить цель загрузки вашей системы по умолчанию с помощью следующей команды:

# systemctl get-default
graphical.target

Подобно системам, использующим SysV, цель по умолчанию никогда не должна указывать на shutdown.target, поскольку она соответствует уровню запуска 0 (завершение работы).

Файлы конфигурации, связанные с каждым модулем, можно найти в каталоге /lib/systemd/system/. Команда systemctl list-unit-files выводит список всех доступных модулей и показывает, разрешено ли им запускаться при загрузке системы. Опция --type выберет только единицы для данного типа, как в systemctl list-unit-files --type=service и systemctl list-unit-files --type=target.

Активные юниты или юниты, которые были активны во время текущего системного сеанса, могут быть перечислены с помощью команды systemctl list-units. Как и опция list-unit-files, команда systemctl list-units --type=service выберет только юниты типа service, а команда systemctl list-units --type=target выберет только юниты типа target.

Команда systemd также отвечает за запуск и реакцию на события, связанные с питанием. Команда systemctl suspend переведет систему в режим низкого энергопотребления, сохраняя текущие данные в памяти. Команда systemctl hibernate копирует все данные из памяти на диск, поэтому текущее состояние системы может быть восстановлено после ее выключения. Действия, связанные с такими событиями, определены в файле /etc/systemd/logind.conf или в отдельных файлах внутри каталога /etc/systemd/logind.conf.d/. Однако эту функцию systemd можно использовать только тогда, когда в системе не запущен другой менеджер питания, например, демон acpid. Демон acpid является основным диспетчером питания для Linux и позволяет более точно настраивать действия после событий, связанных с питанием, таких как закрытие крышки ноутбука, низкий уровень заряда батареи или уровни заряда батареи.

Upstart - устарел.

Shutdown and Restart

Команда, используемая для выключения или перезапуска системы, называется shutdown. Команда shutdown добавляет дополнительные функции к процессу отключения питания: она автоматически уведомляет всех вошедших в систему пользователей предупреждающим сообщением в их shell сеансах, и блокирует новые входы в систему. Команда shutdown действует как посредник для процедур SysV или systemd, то есть выполняет запрошенное действие, вызывая соответствующее действие в диспетчере служб, принятом системой.

После завершения работы все процессы получают сигнал SIGTERM, за которым следует сигнал SIGKILL, затем система выключается или меняет уровень выполнения. По умолчанию, если не используются параметры -h или -r, то система переходит на уровень выполнения 1, то есть в однопользовательский режим. Чтобы изменить параметры выключения по умолчанию, команду следует выполнить со следующим синтаксисом:

$ shutdown [option] time [message]

Обязательным является только параметр времени, который может принимать форматы hh:mm или +m или now

Параметр message - это сообщение которое будет передано всем пользователям перед отключением системы.

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

$ sudo which poweroff
/usr/sbin/poweroff
$ sudo ls -l /usr/sbin/poweroff
lrwxrwxrwx 1 root root 14 Aug 20 07:50 /usr/sbin/poweroff -> /bin/systemctl
Выводы

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

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

< Лекция 1 || Лекция 2: 123456 || Лекция 3 >
Рустам Тагаев
Рустам Тагаев

Очень много ошибок в тестах. Другие люди их тоже нашли. Но прошло очень много времени и похоже что ошибки не собираются исправлять. Очень обидно что на такой большой платформе такая медленная реакция.