Systemctl команда не найдена centos 6
systemd — это система инициализации и системный диспетчер, который стал новым стандартом для дистрибутивов Linux. Из-за сложной адаптивности знакомство с системой systemd оправдано, поскольку это существенно упростит администрирование серверов. Изучение и использование инструментов и демонов, которые включают systemd , поможет вам лучше оценить предоставляемые возможности и гибкость или, по крайней мере, работать с минимальным количеством проблем.
В этом руководстве мы обсудим команду systemctl , которая является инструментом центрального управления для контроля системы инициализации. Мы расскажем о том, как управлять службами, проверять статус, изменять состояние системы и работать с файлами конфигурации.
Обратите внимание, что хотя система systemd стала системой инициализации по умолчанию для многих дистрибутивов Linux, она не используется повсеместно во всех дистрибутивах. По мере изучения этого руководства, если ваш терминал выводит ошибку bash: systemctl is not installed , скорее всего, на вашей машине установлена другая система инициализации.
Управление службами
Основополагающая цель системы инициализации заключается в инициализации компонентов, которые должны запускаться после загрузки ядра Linux (традиционно называются компоненты пользовательского пространства). Система инициализации также используется для управления службами и демонами для сервера и в любой момент времени работы системы. С учетом этого мы начнем с нескольких базовых операций по управлению службами.
В systemd целью большинства действий являются «модули», являющиеся ресурсами, которыми systemd знает, как управлять. Модули распределяются по категориям по типу ресурса, который они представляют, и определяются файлами, известными как файлы модулей. Тип каждого модуля можно вывести из суффикса в конце файла.
Для задач по управлению службами целевым модулем будут модули службы, которые имеют файлы модулей с суффиксом .service . Однако для большинства команд по управлению службами вы можете не использовать суффикс .service , поскольку systemd достаточно умна, чтобы знать, что вы, возможно, хотите работать со службой при использовании команд по управлению службами.
Запуск и остановка служб
Чтобы запустить службу systemd , используя инструкции в файле модуля службы, используйте команду start . Если вы работаете как пользователь без прав root, вам потребуется использовать sudo , поскольку это влияет на состояние операционной системы:
Как мы уже упомянули выше, systemd будет искать файлы *.service для команд управления службами, так что команду можно легко ввести следующим образом:
Хотя вы можете использовать вышеуказанный формат для общего администрирования, для ясности мы будем использовать суффикс .service для остальных команд, чтобы предельно четко выражать цель, над которой мы работаем.
Чтобы остановить работающую в данный момент службу, можно использовать команду stop :
Перезапуск и перезагрузка
Чтобы перезапустить работающую службу, можно использовать команду restart :
Если данное приложение может перезагрузить файлы конфигурации (без перезапуска), вы можете выдать команду reload для инициализации этого процесса:
Если вы не уверены, есть ли у службы функция перезагрузки своей конфигурации, можно использовать команду reload-or-restart . Это перезагрузит необходимую конфигурацию при наличии. В противном случае будет перезагружена служба для выбора новой конфигурации:
Включение и отключение служб
Указанные выше команды полезны для запуска или остановки служб во время текущего сеанса. Чтобы дать команду systemd автоматически запускать службы при загрузке, их необходимо включить.
Для запуска службы во время загрузки используйте команду enable :
При этом будет создана символическая ссылка из системной копии служебного файла (обычно в /lib/systemd/system или /etc/systemd/system ) в месте на диске, где systemd ищет файлы для автозапуска (обычно /etc/systemd/system/ some_target .target.wants ; что такое цель, мы рассмотрим далее в этом руководстве).
Чтобы отключить автоматический запуск службы, можно ввести следующее:
При этом будет удалена символическая ссылка, что укажет на то, что служба не должна запускаться автоматически.
Помните, что включение службы не запустит ее в текущем сеансе. Если вы хотите запустить службу и включить ее при загрузке, необходимо дать обе команды, start и enable .
Проверка статуса служб
Чтобы проверить статус службы в вашей системе, можно использовать команду status :
При этом вы получите статус службы, иерархию контрольных групп и первые несколько строк журнала.
Например, при проверке статуса сервера Nginx вы можете видеть следующий вывод:
Это дает вам хороший обзор текущего статуса приложения и уведомляет о наличии каких-либо проблем или необходимости выполнения каких-либо действий.
Также есть методы для проверки определенных статусов. Например, чтобы проверить, активен ли (работает ли) модуль в данный момент, можно использовать команду is-active :
Это вернет текущий статус модуля, который обычно active или inactive . Код выхода будет «0», если он активен, и результат будет проще парсить в скрипты оболочки.
Чтобы увидеть, включен ли модуль, можно использовать команду is-enabled :
Это выведет информацию о том, что служба enabled или disabled , и снова установит код выхода на «0» или «1» в зависимости от вопроса команды.
Третья проверка заключается в проверке того, находится ли модуль в состоянии сбоя. Это означает, что была проблема, которая запустила данный модуль:
Это вернет active , если он работает должным образом, или failed , если возникла ошибка. Если модуль был намеренно остановлен, может вернуться unknown или inactive . Статус выхода «0» означает, что произошел сбой, а статус выхода «1» указывает на какой-либо другой статус.
Обзор состояния системы
Команды до сих пор были полезны для управления отдельными службами, но они не очень подходят для понимания текущего состояния системы. Существует ряд команд systemctl , предоставляющих эту информацию.
Список текущих модулей
Чтобы увидеть список всех активных модулей, о которых знает systemd , можно использовать команду list-units :
Это покажет вам список всех модулей, которые у systemd активны в системе. Результат будет выглядеть примерно так:
Вывод содержит следующие столбцы:
- UNIT: имя модуля systemd
- LOAD: указывает на то, парсила ли systemd конфигурацию модуля. Конфигурация загруженных модулей сохраняется в памяти.
- ACTIVE: краткое состояние активности модуля. Обычно это довольно стандартный способ сообщить, запущен модуль или нет.
- SUB: это состояние более низкого уровня, которое указывает более подробную информацию о модуле. Это часто зависит от типа модуля, состояния и фактического метода работы модуля.
- DESCRIPTION: краткое текстовое описание того, чем является модуль/что делает.
Поскольку команда list-units показывает по умолчанию только активные модули, для всех вводов выше отобразится loaded в столбце LOAD и active в столбце ACTIVE. Это отображение фактически является поведением по умолчанию systemctl при вызове без дополнительных команд, поэтому вы увидите то же, что и при вызове systemctl без аргументов:
Мы можем использовать systemctl для вывода различной информации путем добавления дополнительных флагов. Например, чтобы увидеть все модули, которые загрузила система systemd (или пыталась загрузить), независимо от их активности в данный момент, можно использовать следующий флаг --all :
Это отобразит все модули, которые загрузила или пыталась загрузить система systemd независимо от текущего состояния системы. Некоторые модули становятся неактивными после работы, а некоторые модули, которые система systemd пыталась загрузить, могут не быть найдены на диске.
Вы можете использовать другие флаги для фильтрации этих результатов. Например, мы можем использовать флаг --state= для указания состояния LOAD, ACTIVE или SUB, которое мы хотим увидеть. Вам потребуется сохранить флаг --all , чтобы systemctl позволила отображать неактивные модули:
Другим распространенным фильтром является фильтр - --type= . Мы можем задать systemctl только для отображения модулей интересующего нас типа. Например, чтобы увидеть только активные модули службы, мы можем:
Список все файлов модулей
Команда list-units отображает только модули, которые система systemd пыталась парсить или загрузить в память. Поскольку systemd будет считывать только те модули, которые считает необходимыми, это необязательно будут все модули, доступные в системе. Чтобы увидеть все доступные файлы модулей в путях systemd , включая те, что система systemd пыталась загрузить, можно использовать команду list-unit-files :
Модули являются представлениями ресурсов, о которых знает systemd . Поскольку система systemd необязательно считывала все определения модуля в этом виде, она представляет информацию только о самих файлах. Вывод содержит два столбца: файл модуля и состояние.
Состояние будет, как правило, enabled , disabled , static или masked . В этом контексте static обозначает, что файл модуля не содержит раздел install , который используется для включения модуля. Эти модули как таковые не могут быть включены. Обычно это означает, что модуль выполняет разовое действие или используется только как зависимость другого модуля и не должен работать самостоятельно.
Мы рассмотрим сразу же, что означает masked .
Управление модулями
До сих пор мы работали со службами и отображали информацию о модулях и файлах модулей, о которых знает systemd . Однако мы можем узнать более конкретную информацию о модулях, используя некоторые дополнительные команды.
Отображение файла модуля
Чтобы отобразить файл модуля, который система systemd загрузила в систему, можно использовать команду cat (она была добавлена в версию systemd 209). Например, чтобы увидеть файл модуля демона-планировщика atd , можно ввести следующее:
Вывод — это файл модуля, известный выполняемому в настоящее время процессу systemd . Это может быть важно, если вы недавно модифицировали файлы модуля или если вы переопределяете определенные опции во фрагменте файла модуля (мы рассмотрим это позже).
Отображение зависимостей
Чтобы увидеть дерево зависимостей модуля, можно использовать команду list-dependencies :
При этом отобразится иерархическая схема зависимостей, с которой необходимо работать, чтобы запустить интересуемый модуль. Зависимости в этом контексте включают те модули, которые либо требуются, либо желательны для модулей выше.
Рекурсивные зависимости отображаются только для модулей .target , которые указывают состояние системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг --all .
Чтобы отобразить обратные зависимости (модули, зависящие от указанного модуля), можно добавить в команду флаг --reverse . Другие полезные флаги --before и --after могут быть использованы для отображения модулей, которые зависят от указанного модуля, соответственно, перед ними и после.
Проверка свойств модуля
Чтобы увидеть свойства более низкого уровня модуля, можно использовать команду show . При этом будет выведен список свойств, заданных для указанного модуля с помощью формата key=value :
Если вы хотите отобразить одно свойство, можно передать флаг -p с именем свойства. Например, чтобы увидеть конфликты, которые есть у модуля sshd.service , можно ввести следующее:
Маскировка и снятие маскировки модулей
В разделе управления службами мы узнали, как остановить или отключить службу, но systemd также имеет возможность отметить модуль как полностью незапускаемый, автоматически или вручную, связав его с /dev/null . Это называется маскировкой модуля, и она возможна с помощью команды mask :
Это не позволит запустить службу Nginx автоматически или вручную, пока она замаскирована.
Если вы проверите list-unit-files , вы увидите, что служба теперь указана как замаскированная:
Чтобы снять маскировку модуля и сделать его доступным для использования снова, используйте команду unmask :
Это вернет модуль в его предыдущее состояние, что позволит его запускать или включать.
Редактирование файлов модулей
Хотя конкретный формат файлов модулей выходит за рамки этого руководства, systemctl предоставляет встроенные механизмы для редактирования и модификации файлов модулей при необходимости изменений. Эта функция добавлена в версию systemd 218.
Команда edit по умолчанию откроет фрагмент файла модуля для интересующего модуля:
Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение модуля. Каталог будет создан в каталоге /etc/systemd/system , который содержит название модуля с добавлением .d . Например, для nginx.service будет создан каталог под названием nginx.service.d .
В этом каталоге будет создан фрагмент под названием override.conf . При загрузке модуля systemd в памяти соединит фрагмент переопределения с полным файлом модуля. Директивы фрагмента получат приоритет над найденными в оригинальном файле модуля.
Если вы хотите редактировать весь файл модуля, а не создавать фрагмент, можно передать флаг --full :
Это загрузит текущий файл модуля в редактор, где его можно редактировать. После выхода из редактора измененный файл будет записан в /etc/systemd/system , что будет иметь приоритет над определением модуля системы (обычно находится где-то в /lib/systemd/system ).
Чтобы удалить какие-либо сделанные добавления, удалите либо каталог конфигурации модуля .d или модифицированный служебный файл из /etc/systemd/system . Например, для удаления фрагмента можно ввести следующее:
Чтобы удалить весь отредактированный файл модуля, добавим:
После удаления файла или каталога необходимо перезагрузить процесс systemd , чтобы он больше не пытался ссылаться на эти файлы и не возвращался к использованию системных копий. Для этого можно ввести следующую команду:
Настройка состояния системы (уровень запуска) с помощью целей
Целями являются специальные файлы модулей, которые описывают состояние системы или точку синхронизации. Как и другие модули, файлы, которые определяют цели, могут быть идентифицированы по суффиксу, которым в данном случае является .target . Цели сами по себе немного значат, а используются для группировки других модулей.
Их можно использовать, чтобы привести систему в определенные состояния, подобно тому, как другие системы инициализации используют уровни запуска. Они используются в качестве справки, когда доступны определенные функции, позволяя вам указывать желаемое состояние вместо необходимости использования отдельных модулей для получения этого состояния.
Например, swap.target используется для указания того, что переключение готово к использованию. Модули, являющиеся частью этого процесса, могут синхронизироваться с этой целью путем указания в своей конфигурации, что они WantedBy= или RequiredBy= swap.target . Модули, которым требуется возможность переключения, могут указывать это состояние с помощью спецификаций Wants= , Requires= и After= для указания характера их отношений.
Получение и настройка цели по умолчанию
Процесс systemd имеет цель по умолчанию, которую он использует при загрузке системы. Удовлетворение каскада зависимостей от этой одной цели приведет систему в желаемое состояние. Чтобы найти цель по умолчанию для вашей системы, введите:
Если вы хотите задать другую цель по умолчанию, можно использовать set-default . Например, если у вас установлен графический рабочий стол и вы хотите загрузить систему в него по умолчанию, можно изменить цель по умолчанию соответственно:
Список доступных целей
Вы можете получить список имеющихся целей в вашей системе, введя:
В отличие от уровней запуска, несколько целей могут быть активны одновременно. Активная цель указывает, что система systemd попыталась запустить все модули, привязанные к цели, и не попыталась закрыть их снова. Чтобы увидеть все активные цели, введите:
Изолирование целей
Можно запустить все модули, связанные с целью, и остановить все модули, не являющиеся частью дерева зависимостей. Команда, необходимая для этого, называется соответственно isolate . Она аналогична изменению уровня запуска в других системах инициализации.
Например, если вы работаете в графической среде с активным graphical.target , можно закрыть графическую систему и перевести систему в состояние многопользовательской командной строки путем изоляции multi-user.target . Поскольку graphical.target зависит от multi-user.target , а не наоборот, все графические модули будут остановлены.
Возможно, вы захотите посмотреть на зависимости цели, которую вы изолируете, перед выполнением этой процедуры, чтобы убедиться, что не остановлены важные службы:
Если вы удовлетворены модулями, которые будут сохранены в активном состоянии, можно изолировать цель, введя:
Использование комбинации быстрого ввода для важных событий
Для таких важных событий, как отключение или перезагрузка, определены цели. Однако для systemctl также есть несколько комбинаций быстрого ввода, обеспечивающих дополнительную функциональность.
Например, чтобы перевести систему в режим спасения (один пользователь), можно использовать команду rescue вместо isolate rescue.target :
Это обеспечит дополнительную функцию предупреждения всех подключенных пользователей о событии.
Чтобы остановить систему, можно использовать команду halt :
Для инициализации полного отключения можно использовать команду poweroff :
Перезапуск можно начать с помощью команды reboot :
Все это оповестит подключенных пользователей о том, что происходит событие, что-то, что только выполняет или изолирует цель, не сработает. Обратите внимание, что большинство машин будет привязывать более короткие, более традиционные команды для этих операций, чтобы правильно работать с systemd .
Например, для перезагрузки системы обычно можно ввести следующее:
Заключение
К этому моменту вы должны уже ознакомиться с некоторыми базовыми возможностями команды systemctl , которая позволяет взаимодействовать и контролировать экземпляр systemd . Утилита systemctl будет главной точкой взаимодействия для управления службами и состоянием системы.
Хотя systemctl работает главным образом с основным процессом systemd , в экосистеме systemd есть другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналами и сеансы пользователя, обрабатываются отдельными демонами и утилитами управления ( journald / journalctl и logind / loginctl соответственно). Знакомство с этими другими инструментами и демонами упростит задачу управления.
Вместе с подсистемой systemd появилась команда systemctl. Она позволяет управлять основными процессами Linux. Ниже представлена небольшая инструкция в виде шпаргалки наиболее используемых команд.
Общий синтаксис
Без параметров, systemctl показывает список запущенных служб, точек монтирования, устройств и других юнитов.
Примерный вывод команды:
1) название юнита;
2) тип юнита (например, service: служба или демон, mount: точка монтирования, device: устройства);
3) состояние юнита (загружен или нет);
4) обобщенный статус юнита (active: выполняется, inactive: не был запущен, maintenance: требуется внимание администратора);
5) текущий статус (запущен или нет);
6) описание.
Шпаргалка по часто используемым командам systemctl
1. Посмотреть статус службы:
systemctl status network
* покажет статус службы на примере сети network
2. Запустить сервис:
systemctl start mysql
* запустит сервис баз данных на примере mysql
3. Остановить службу:
systemctl stop ntpd
* остановит сервис времени ntpd
4. Перезапустить службу:
systemctl restart nginx
* перезапустит веб-сервер nginx
5. Включить автозапуск службы:
systemctl enable apache
* разрешит автозапуск веб-сервера apache
6. Отключить автозапуск службы:
systemctl disable firewalld
* запретит автозапуск брандмауэра firewalld
7. Выполнить команду на удаленной системе:
systemctl --host [email protected] stop cron
* остановит cron на компьютере с IP-адресом 192.168.0.15, подключившись под учетной записью root.
8. Перезагрузить сервер:
* перезагрузит локальный сервер.
9. Проверка работы сервиса.
Выполняется с помощью опции is-active:
systemctl is-active docker
* в данном примере мы проверим работу службы docker.
а) Если сервис запущен, мы увидим:
б) Если не запущен:
в) Если такого сервиса нет в системе:
Если сервис не работает или его нет в системе, команда вернет код ошибки, таким образом конструкция:
systemctl is-active docker && docker run hello-world
. приведет к выполнению команды docker run hello-world только в том случае, если сервис docker работает.
Автозапуск
Подсистему systemd также можно использовать для автозапуска сервисов или скриптов. Для этого в каталоге /usr/lib/systemd/system создаем юнит (файл) с расширением .service. Подробнее разберем на примере сервиса bind:
Содержимое может быть следующего содержания:
[Unit]
Description=Berkeley Internet Name Domain (DNS)
Wants=nss-lookup.target
Wants=named-setup-rndc.service
Before=nss-lookup.target
After=network.target
After=named-setup-rndc.service
* как правило, файл разделен на 3 части:
- Unit — позволяет определить метаданные для юнита.
- Service — раздел для основной конфигурации юнита.
- Install — определение поведения для юнита при его включении или отключении.
После внесения изменений и сохранения файла, необходимо перечитать изменения командой:
Теперь можно разрешить автозапуск:
systemctl enable named
Редактирование сервисов
Если мы хотим внести изменения в юнит-файл сервиса, который был установлен с последним, необходимо использовать drop-in файл или файл переопределения настроек. В противном случае, после обновления программы наши изменения могут быть удалены.
И так, мы для примера взяли юнит для bind. Чтобы создать для него drop-in файл, вводим:
Понимание процедуры загрузки в Linux RHEL7/CentOS
Следующие шаги суммируют, как процедура загрузки происходит в Linux.
1. Выполнение POST: машина включена. Из системного ПО, которым может быть UEFI или классический BIOS, выполняется самотестирование при включении питания (POST) и аппаратное обеспечение, необходимое для запуска инициализации системы.
2. Выбор загрузочного устройства: В загрузочной прошивке UEFI или в основной загрузочной записи находится загрузочное устройство.
3. Загрузка загрузчика: с загрузочного устройства находится загрузчик. На Red Hat/CentOS это обычно GRUB 2.
4. Загрузка ядра: Загрузчик может представить пользователю меню загрузки или может быть настроен на автоматический запуск Linux по умолчанию. Для загрузки Linux ядро загружается вместе с initramfs . Initramfs содержит модули ядра для всего оборудования, которое требуется для загрузки, а также начальные сценарии, необходимые для перехода к следующему этапу загрузки. На RHEL 7/CentOS initramfs содержит полную операционную систему (которая может использоваться для устранения неполадок).
5. Запуск /sbin/init: Как только ядро загружено в память, загружается первый из всех процессов, но все еще из initramfs . Это процесс /sbin/init , который связан с systemd . Демон udev также загружается для дальнейшей инициализации оборудования. Все это все еще происходит из образа initramfs .
6. Обработка initrd.target: процесс systemd выполняет все юниты из initrd.target , который подготавливает минимальную операционную среду, в которой корневая файловая система на диске монтируется в каталог /sysroot . На данный момент загружено достаточно, чтобы перейти к установке системы, которая была записана на жесткий диск.
7. Переключение на корневую файловую систему: система переключается на корневую файловую систему, которая находится на диске, и в этот момент может также загрузить процесс systemd с диска.
8. Запуск цели по умолчанию (default target): Systemd ищет цель по умолчанию для выполнения и запускает все свои юниты. В этом процессе отображается экран входа в систему, и пользователь может проходить аутентификацию. Обратите внимание, что приглашение к входу в систему может быть запрошено до успешной загрузки всех файлов модуля systemd . Таким образом, просмотр приглашения на вход в систему не обязательно означает, что сервер еще полностью функционирует.
На каждом из перечисленных этапов могут возникнуть проблемы из-за неправильной настройки или других проблем. Таблица суммирует, где настроена определенная фаза и что вы можете сделать, чтобы устранить неполадки, если что-то пойдет не так.
Передача аргементов в GRUB 2 ядру во время загрузки
Если сервер не загружается нормально, приглашение загрузки GRUB предлагает удобный способ остановить процедуру загрузки и передать конкретные параметры ядру во время загрузки. В этой части вы узнаете, как получить доступ к приглашению к загрузке и как передать конкретные аргументы загрузки ядру во время загрузки.
Когда сервер загружается, вы кратко видите меню GRUB 2. Смотри быстро, потому что это будет длиться всего несколько секунд. В этом загрузочном меню вы можете ввести e, чтобы войти в режим, в котором вы можете редактировать команды, или c, чтобы ввести полную командную строку GRUB.
После передачи e в загрузочное меню GRUB вы увидите интерфейс, показанный на скриншоте ниже. В этом интерфейсе прокрутите вниз, чтобы найти раздел, начинающийся с linux16 /vmlinuz , за которым следует множество аргументов. Это строка, которая сообщает GRUB, как запустить ядро, и по умолчанию это выглядит так:
После ввода параметров загрузки, которые вы хотите использовать, нажмите Ctrl + X, чтобы запустить ядро с этими параметрами. Обратите внимание, что эти параметры используются только один раз и не являются постоянными. Чтобы сделать их постоянными, вы должны изменить содержимое файла конфигурации /etc/default/grub и использовать grub2-mkconfig -o /boot/grub2/grub.cfg , чтобы применить изменение.
Когда у вас возникли проблемы, у вас есть несколько вариантов (целей), которые вы можете ввести в приглашении загрузки GRUB:
■ rd.break Это останавливает процедуру загрузки, пока она еще находится в стадии initramfs .
Эта опция полезна, если у вас нет пароля root.
■ init=/bin/sh или init=/bin/bash Указывает, что оболочка должна быть запущена сразу после загрузки ядра и initrd . Это полезный вариант, но не лучший, потому что в некоторых случаях вы потеряете консольный доступ или пропустите другие функции.
■ systemd.unit=rescue.target Команда запускает еще несколько системных юнитов, чтобы привести вас в более полный рабочий режим. Требуется пароль root.
Чтобы увидеть, что загружено только очень ограниченное количество юнит-файлов, вы можете ввести команду systemctl list-units .
Запуск целей(targets) устранения неполадок в Linux
1. (Пере)загружаем Linux. Когда отобразиться меню GRUB, нажимаем e ;
2. Находим строку, которая начинается на linux16 /vmlinuz. В конце строки вводим systemd.unit=rescue.target и удаляем rhgb quit ;
3. Жмем Ctrl+X, чтобы начать загрузку с этими параметрами. Вводим пароль от root;
4. Вводим systemctl list-units и смотрим. Будут показаны все юнит-файлы, которые загружены в данный момент и соответственно загружена базовая системная среда;
5. Вводим systemctl show-environment . Видим переменные окружения в режиме rescue.target;
6. Перезагружаемся reboot ;
7. Когда отобразится меню GRUB, нажимаем e . Находим строку, которая начинается на linux16 /vmlinuz. В конце строки вводим systemd.unit=emergency.target и удаляем rhgb quit ;
8. Снова вводим пароль от root;
9. Система загрузилась в режиме emergency.target;
10. Вводим systemctl list-units и видим, что загрузился самый минимум из юнит-файлов.
Устранение неполадок с помощью загрузочного диска Linux
Еще один способ восстановления работоспособности Linux использовать образ операционки.
Если вам повезет меньше, вы увидите мигающий курсор в системе, которая вообще не загружается. Если это произойдет, вам нужен аварийный диск. Образ восстановления по умолчанию для Linux находится на установочном диске. При загрузке с установочного диска вы увидите пункт меню "Troubleshooting". Выберите этот пункт, чтобы получить доступ к параметрам, необходимым для ремонта машины.
- Install CentOS 7 in Basic Graphics Mode: эта опция переустанавливает систему. Не используйте её, если не хотите устранить неполадки в ситуации, когда обычная установка не работает и вам необходим базовый графический режим. Как правило, вам никогда не нужно использовать эту опцию для устранения неисправностей при установке.
- Rescue a CentOS System: это самая гибкая система спасения. Это должен быть первый вариант выбора при использовании аварийного диска.
- Run a Memory Test: если вы столкнулись с ошибками памяти, это позволяет пометить плохие микросхемы памяти, чтобы ваша машина могла нормально загружаться.
- Boot from local drive: здесь я думаю всё понятно.
Пример использования "Rescue a CentOS System"
1. Перезагружаем сервер с установочным диском Centos 7. Загружаемся и выбираем "Troubleshooting".
2. В меню траблшутинга выбираем "Rescue a CentOS System" и загружаемся.
3. Система восстановления теперь предлагает вам найти установленную систему Linux и смонтировать ее в /mnt/sysimage . Выберите номер 1, чтобы продолжить:
4. Если была найдена правильная установка CentOS, вам будет предложено, чтобы система была смонтирована в /mnt/sysimage . В этот момент вы можете дважды нажать Enter, чтобы получить доступ к оболочке восстановления.
5. Ваша система Linux на данный момент доступна через каталог /mnt/sysimage . Введите chroot /mnt/sysimage . На этом этапе у вас есть доступ к корневой файловой системе, и вы можете получить доступ ко всем инструментам, которые необходимы для восстановления доступа к вашей системе.
Переустановка GRUB с помощью аварийного диска
Одна из распространенных причин, по которой вам нужно запустить аварийный диск, заключается в том, что загрузчик GRUB 2 не работает. Если это произойдет, вам может понадобиться установить его снова. После того, как вы восстановили доступ к своему серверу с помощью аварийного диска, переустановить GRUB 2 несложно, и он состоит из двух этапов:
- Убедитесь, что вы поместили содержимое каталога /mnt/sysimage в текущую рабочую среду.
- Используйте команду grub2-install , а затем имя устройства, на котором вы хотите переустановить GRUB 2. Если это виртуальная машина KVM используйте команду grub2-install /dev/vda и на физическом сервере или виртуальная машина VMware, HyperV или Virtual Box, это grub2-install /dev/sda .
Повторное создание Initramfs с помощью аварийного диска
Иногда initramfs также может быть поврежден. Если это произойдет, вы не сможете загрузить свой сервер в нормальном рабочем режиме. Чтобы восстановить образ initramfs после загрузки в среду восстановления, вы можете использовать команду dracut . Если используется без аргументов, эта команда создает новый initramfs для загруженного в данный момент ядра.
Кроме того, вы можете использовать команду dracut с несколькими опциями для создания initramfs для конкретных сред ядра. Существует также файл конфигурации с именем /etc/dracut.conf , который можно использовать для включения определенных параметров при повторном создании initramfs .
- /usr/lib/dracut/dracut.conf.d/*.conf содержит системные файлы конфигурации по умолчанию.
- /etc/dracut.conf.d содержит пользовательские файлы конфигурации dracut.
- /etc/dracut.conf используется в качестве основного файла конфигурации.
Исправление общих проблем
В пределах статьи, подобной этой, невозможно рассмотреть все возможные проблемы, с которыми можно столкнуться при работе с Linux. Однако есть некоторые проблемы, которые встречаются чаще, чем другие. Ниже некоторые наиболее распространенные проблемы.
Переустановка GRUB 2
Код загрузчика не исчезает просто так, но иногда может случиться, что загрузочный код GRUB 2 будет поврежден. В этом случае вам лучше знать, как переустановить GRUB 2. Точный подход зависит от того, находится ли ваш сервер в загрузочном состоянии. Если это так, то довольно просто переустановить GRUB 2. Просто введите grub2-install и имя устройства, на которое вы хотите его установить. У команды есть много различных опций для точной настройки того, что именно будет установлено, но вам, вероятно, они не понадобятся, потому что по умолчанию команда устанавливает все необходимое, чтобы ваша система снова загрузилась. Становится немного сложнее, если ваш сервер не загружается.Если это произойдет, вам сначала нужно запустить систему восстановления и восстановить доступ к вашему серверу из системы восстановления. После монтирования файловых систем вашего сервера в /mnt/sysimage и использования chroot /mnt/sysimage , чтобы сделать смонтированный образ системы вашим корневым образом: Просто запустите grub2-install , чтобы установить GRUB 2 на желаемое установочное устройство. Но если вы находитесь на виртуальной машине KVM, запустите grub2-install /dev/vda , а если вы находитесь на физическом диске, запустите grub2-install /dev/sda .
Исправление Initramfs
В редких случаях может случиться так, что initramfs будет поврежден. Если вы тщательно проанализируете процедуру загрузки, вы узнаете, что у вас есть проблема с initramfs , потому что вы никогда не увидите, как корневая файловая система монтируется в корневой каталог, и при этом вы не увидите запуска каких-либо системных модулей. Если вы подозреваете, что у вас есть проблема с initramfs , ее легко создать заново. Чтобы воссоздать его, используя все настройки по умолчанию (что в большинстве случаев нормально), вы можете просто запустить команду dracut --force . (Без --force команда откажется перезаписать ваши существующие initramfs .)
При запуске команды dracut вы можете использовать файл конфигурации /etc/dracut.conf , чтобы указать, что именно записывается в initramfs . В этом файле конфигурации вы можете увидеть такие параметры, как lvmconf = «no» , которые можно использовать для включения или выключения определенных функций. Используйте эти параметры, чтобы убедиться, что у вас есть все необходимые функции в initramfs .
Восстановление после проблем с файловой системой
В операционной системе linux, так же как и в Windows, кроме обычных программ, которые могут взаимодействовать с пользователем есть еще один вид программ. Это работающие в фоне службы. Важность служб тяжело переоценить, они следят за состоянием системы, обеспечивают автоматическое подключение внешних устройств и сети, позволяют процессам взаимодействовать с оборудованием (dbus), а также в виде служб реализованы различные веб-серверы и серверы баз данных. В отличие от пользовательских программ, службы выполняются в фоне, и пользователь не имеет к ним прямого доступа. Пользователь еще не вошел в систему, только началась загрузка а основные службы уже запущенны и работают.
В этой статье мы рассмотрим управление службами Linux. Мы не будем трогать уже устаревшие системы, такие как SysVinit, сосредоточимся только на Systemd. Вы узнаете, как посмотреть запущенные службы linux, а также останавливать и запускать их самому.
Немного теории
Но потом на смену этому методу пришла новая модель и система инициализации systemd. Система инициализации запускается сразу после загрузки ядра и начинает инициализировать службы, теперь появилась возможность параллельной инициализации, а также зависимостей между службами. Таким образом, теперь можно определить сложное дерево порядка запуска служб. Но мы не будем вникать в подробности создания служб, нас интересует только сам процесс запуска. После запуска systemd собирает весь вывод службы в лог, и следит за ее работой, если служба аварийно завершилась, то автоматически ее перезапускает.
Служба в Systemd описывается файлом юнита, в нем описано что с ней нужно делать и как себя вести. Существуют такие типы служб:
- service - обычная служба, программа
- target - группа служб
- automount - точка автоматического монтирования
- device - файл устройства, генерируется на этапе загрузки
- mount - точка монтирования
- path - файл или папка
- scope - процесс
- slice - группа системных служб systemd
- snapshot - сохраненное состояние запущенных служб
- socket - сокет для взаимодействия между процессами.
Нас будут интересовать только service, и совсем немного target, но мы рассмотрели все остальные, чтобы вы смогли взглянуть на картину немного шире. Основы рассмотрели, теперь будет настройка служб LInux.
Утилита systemctl
В Systemd есть специальный инструмент для управления службами в Linux - systemctl. Эта утилита позволяет делать очень много вещей, начиная от перезапуска службы linux и проверки ее состояния, до анализа эффективности загрузки службы. Синтаксис у утилиты такой:
$ systemctl опции команда служба служба.
Опции настраивают поведение программы, подробность вывода, команда - указывает что нужно сделать со службой, а служба, это та самая служба, которой мы собираемся управлять. В некоторых случаях утилита может использоваться без указания команды и службы.
Рассмотрим все по порядку. Опции очень сильно зависят от команд, поэтому рассмотрим их позже, а пока пройдемся по командах:
А теперь основные опции:
Как видите, опции будут мало полезны и лучше обратить больше внимания на команды, с помощью них выполняются все действия.
Управление службами Linux
Теперь, когда вы уже знаете все основы, команды и параметры можно переходить к делу. Со всеми остальными тонкостями разберемся по пути. Сначала давайте посмотрим запущенные службы linux. Нас будут интересовать только программы, а не все эти дополнительные компоненты, поэтому воспользуемся опцией type:
systemctl list-units --type service
Команда отобразила все службы, которые известны systemd, они сейчас запущены или были запущены. Программа не пересматривает все файлы, поэтому будут показаны только те службы, к которым уже обращались. Состояние loaded - означает, что конфигурационный файл был успешно загружен, следующая колонка active - служба была запущена, а running или exited значит выполняется ли сейчас служба или она успешно завершила свою работу. Листать список можно кнопками вверх/вниз.
Следующая команда позволяет получить список служб linux, в который входят все службы, даже не запущенные, те, которые не запускались, но известны systemd, но это еще не все службы в системе:
systemctl list-units --type service -all
Дальше больше. Вы можете отсортировать список служб systemctl по состоянию. Например, только выполняющиеся:
systemctl list-units --type service --state running
Или те, которые завершились с ошибкой:
systemctl list-units --type service --state failed
Для фильтрации можно брать любой показатель состояния из любой колонки. Другой командой мы можем посмотреть все файлы конфигурации служб на диске. Тут не будем фильтровать по типу, пусть программа покажет все:
Теперь отфильтруем только службы linux:
systemctl list-unit-files --type service
Здесь вы тоже можете использовать фильтры по состоянию. Теперь вы знаете как посмотреть запущенные службы linux, идем дальше.
Чтобы запустить службу используется команда start, например:
sudo systemctl start application.service
Причем расширение service можно опустить, оно и так подставляется по умолчанию. Если запуск прошел хорошо, программа ничего не выведет.
Остановить службу linux можно командой:
sudo systemctl stop application
Посмотреть состояние службы позволяет команда status:
sudo systemctl status application
Здесь вы можете видеть, состояние running, exited, dead, failed и т д. А также несколько последних строчек вывода программы, которые очень помогут решить проблему с запуском если она возникнет.
Автозагрузка служб в systemd
Как вы знаете, systemd позволяет автоматически загружать службы при запуске системы по мере их надобности. Команда list-unit-files показывает добавлена ли служба в автозагрузку.
Вообще, здесь может быть несколько состояний - enabled - в автозагрузке, disabled - автозагрузка отключена, masked - служба скрыта и static - значит что служба в автозагрузке, но вы не можете ее отключить.
Поэтому чтобы получить список служб linux, запускаемых автоматически достаточно отфильтровать ее вывод по состоянию:
systemctl list-unit-files --state enabled
Все службы, запускаемые по умолчанию. Можете также посмотреть службы static. Чтобы добавить службу в автозагрузку linux используйте команду enable:
sudo systemctl enable application
А для того чтобы убрать ее из автозагрузки:
sudo systemctl disable applciation
Также, вы можете посмотреть разрешена ли сейчас автозагрзука для службы:
sudo systemctl is-enabled application
Утилита просто выведет состояние enabled, disabled или static.
Выводы
Теперь настройка служб Linux не вызовет у вас проблем. Много чего мы упустили, systemd - очень большая, сложная и многофункциональная система, которую не охватить в одной статье. Но и также очень сложно понять. Но я думаю, что все, что касается управления службами Linux мы разобрали. Если у вас остались вопросы, спрашивайте в комментариях!
Читайте также: