26 команд в linux, которые должен знать каждый сисадмин

Настройка клиента

Перед тем, как переходить к настройке клиента, с сервера копируем ключи для CA на клиента. Это можно сделать, например, с помощью scp:

scp /etc/ssl/ca/trusted.{key,pem} user@192.168.0.11:/tmp

* в данном примере мы скопировали два ключа для CA на компьютер 192.168.0.11. Подключение идет от пользователя user, который должен быть на клиенте.

Теперь переходим к компьютеру, который должен отправлять свои логи на сервер. Для его настройки нам нужно также сгенерировать сертификаты, а также настроить и запустить компонент systemd-journal-upload.

Создание сертификата

Создаем каталоги для сертификатов: 

mkdir /etc/ssl/{private,certs,ca}

Копируем наши ключи для CA из каталога /tmp в /etc/ssl/ca:

cp /tmp/trusted.{key,pem} /etc/ssl/ca/

Теперь генериируем сертификат с помощью ключей CA:

openssl genrsa -out /etc/ssl/private/journal-upload.pem 2048

openssl req -new -key /etc/ssl/private/journal-upload.pem -out /etc/ssl/certs/journal-upload.csr -subj «/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=journal-upload»

openssl x509 -req -in /etc/ssl/certs/journal-upload.csr -CA /etc/ssl/ca/trusted.pem -CAkey /etc/ssl/ca/trusted.key -CAcreateserial -out /etc/ssl/certs/journal-upload.pem -days 1825 -sha256

Настройка и запуск journal-upload

Открываем файл для настройки journal-upload:

vi /etc/systemd/journal-upload.conf

Добавляем:

URL=https://journal-server.local:19532

* где journal-server.local — имя сервера логов, которое мы использовали при генерировании сертификата сервера. Обращение к серверу должно идти по имени, которое мы указали в сертификате, в противном случае, мы получим ошибку при запуске сервиса. Таким образом, данное имя должно быть либо в локальном DNS, либо в файле hosts.

Разрешаем автозапуск демона 

systemctl enable systemd-journal-upload

systemctl start systemd-journal-upload

Проверяем, что он корректно запустился:

systemctl status systemd-journal-upload

Спор вокруг систем инициализации в Linux

System V init (или просто «SysV») — это система инициализации, которая существует со времен операционной системы System V, которая была выпущена в 1983 году. SysV оставалась системой инициализации в течение почти трех десятилетий (за некоторыми исключениями). Многие IT-специалисты и программисты в силу своей привычки не хотели отказываться от SysV, да и к тому же она была очень простой для понимания.

Проблема с SysV заключалась в том, что в её основе лежали концепции, существовавшие много лет назад. SysV не хватало возможности нативно обрабатывать многие вещи, такие как: обнаружение съемных носителей, корректное обнаружение аппаратного обеспечения и загрузка встроенного ПО, загрузка различных модулей и пр. Кроме того, при использовании данной системы, инициализация процессов происходит последовательно, т.е. одна задача запускается только после успешного завершения предыдущей. Часто это приводило к задержке и длительному времени загрузки. Задачи, подобные монтированию файловых систем, выполняются один раз во время загрузки, после чего «забываются». Но такого подхода недостаточно для автоматизированного управления сервисами, требующими к себе постоянного внимания.

В попытке привнести больше возможностей в процесс инициализации Linux-систем, компания Canonical в 2006 году вместе с релизом Ubuntu 6.10 (Edgy Eft) выпускает систему инициализации Upstart, которая с самого начала разрабатывалась с учетом обратной совместимости. Она может запускать демоны без каких-либо изменений в их скриптах запуска.

Другой системой инициализации, восходящей своими корнями к операционной системе 4.4BSD, является rc.init. Она применяется в таких дистрибутивах, как: FreeBSD, NetBSD и Slackware. В 2007 году разработчики Gentoo выпустили улучшенный вариант данной системы инициализации, сделав её модульной и назвав OpenRC. Большинство других дистрибутивов Linux исторически продолжало использовать SysV.

В 2010 году инженеры компании Red Hat Леннарт Пёттеринг и Кей Сиверс приступили к разработке новой системы инициализации — systemd, которая разрабатывалась с учетом недостатков, имеющихся в SysV. В состав systemd, помимо прочего, также входят и различные пакеты, утилиты и библиотеки, позволяющие производить параллельный запуск процессов, сокращая тем самым время загрузки системы и количество необходимых вычислений. Весной того же года Fedora 15 стала первым дистрибутивом, в котором по умолчанию использовалась система инициализации systemd. После чего, на протяжении следующих трех лет, большинство дистрибутивов массово перешли на systemd.

Но, если все остальные дистрибутивы отдают предпочтение systemd и считают её лучшей системой инициализации, как для предприятий, так и для любителей, почему так много споров вокруг нее?

systemd, по сравнению с SysV и Upstart, содержит большое количество различных улучшений, а также предлагает и другие компоненты, имеющие более тесную интеграцию с системой, с помощью которых разработчики могут уменьшить объем выполняемой работы. Что в этом плохого? Ну, поскольку разработчики создают программное обеспечение, которое зависит от systemd и/или от любой из её многочисленных служб (journald, udevd, consoled, logind или networkd), то такое ПО становится менее совместимым с системами, в которых systemd не применяется. По мере того, как количество служб, предоставляемых проектом systemd, продолжает расти, systemd сама становится все более зависимой от них.

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

Упрощенный вариант доступа к системному журналу

Возможно, вы не заинтересованы в использовании терминала для доступа к системному журналу. К счастью, существует полезное приложение под названием Logs, которое может быть установлено в дистрибутиве Fedora как редакции Workstation, так и любой другой редакции. Для его установки может использоваться Центр приложений. Данное приложение реализует простой графический интерфейс, позволяющий ознакомиться с содержимым сообщений системного журнала.

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

Надеюсь, что в рамках данной статьи мне удалось продемонстрировать вам некоторые интересные приемы работы с системным журналом. Для получения дополнительной полезной информации рекомендую обратиться к из серии «systemd для системных администраторов». Удачи при работе с системным журналом!

На нашем сайте вы можете прочитать большую серию переводов, посвященных системе инициализации systemd:

• Jon Stanley, перевод: А.Панин, «systemd: преобразование сценариев sysvinit для работы с systemd»
  В данной статье рассматривается методика преобразования устаревших сценариев инициализации,
  которые вы могли модифицировать в соответствии со своими потребностями, для работы с systemd.
• Bryan Sutherland, перевод: А.Панин, «systemd: основные приемы работы с юнит-файлами»
  Система инициализации systemd разделена на множество программных компонентов, что значительно
  упрощает процедуру управления компонентами вашей системы. systemd использует юнит-файлы для
  конфигурации и управления системными ресурсами, такими, как процессы и ваша файловая система.
  Благодаря этим файлам вы можете использовать systemd для конфигурации вашей системы в
  соответствии с вашими пожеланиями.
• Ryan Lerch, перевод: А.Панин, «systemd: что такое система инициализации?»
  systemd является набором инструментов для выполнения широкого спектра системных задач, включая
  инициализацию системы, а также для управления и отслеживания состояния системных служб и демонов
  как в процессе загрузки системы, так и в процессе ее работы.
• Carla Schroder, перевод: Н.Ромоданов, «Управление сервисами в Linux с systemd»
  Вы уже читали все о systemd, новом демоне Linux init. Вы знаете, что он делает, и почему.
  Теперь пришло время окунуться глубже и узнать, как он себя ведет — или, по крайней мере, как
  запускает, останавливает и выдает информацию о сервисах.
• Carla Schroder, перевод: Н.Ромоданов, «Знакомимся с уровнями запуска Systemd и командами управления сервисами»
  В прошлом у нас были статические уровни запуска. Вместо уровней запуска, systemd позволяет
  создавать различные состояния, предоставляя вам гибкий механизм создания различных конфигураций
  загрузки.
• Carla Schroder, перевод: Н.Ромоданов, «Изучаем и используем Systemd»
  Ценность systemd является спорной по нескольким причинам: он заменяет то, что, как думают
  многие пользователи Linux, заменять не требуется, и все гримасы разработчиков systemd не
  завоевывают сердца и умы.
• Carla Schroder, перевод: Н.Ромоданов, «Проходим еще раз, еще один Linux Init: введение в systemd»
  В течение очень многих лет в системе Linux для управления запуском системы хватало механизма
  sysvinit. Затем появились две новых системы инициализации Linux: Ubuntu’s Upstart, впервые
  выпущенная в 2006 году, и systemd, появившаяся в 2009 году. Что же это за штуковина systemd,
  и какие преимущества она даст нам, простым пользователям Linux? Н.Ромоданов перевел 4 статьи
  о systemd, первую из которых вы можете прочесть сегодня.

Настройка rsyslogd

Объекты, приоритеты, и места назначения

Объект Приоритет Назначение 

Доступные объекты и приоритеты являются фиксированными и не могут быть добавлены. Таблица 2 показывает, какие объекты доступны, а таблица 3 показывает список всех приоритетов.имя_модуля

Объект	Что логируется
auth / authpriv	Сообщения, связанные с аутентификацией.
cron	Сообщения, сгенерированные сервисом crond.
daemon	Универсальный объект, который можно использовать для неопределенных демонов.
kern	Сообщения ядра.
lpr	Сообщения, сгенерированные через систему печати.
mail	Сообщения, связанные с электронной почтой.
mark	Специальный объект, который можно использовать для периодической записи маркера.
news	Сообщения, генерируемые системой новостей NNTP.
security	То же, что и auth / authpriv. Не должен больше использоваться.
syslog	Сообщения, генерируемые системой syslog.
user	Сообщения генерируемые в пространстве пользователя.
uucp	Сообщения, сгенерированные устаревшей системой UUCP.
local0-7	Резервные объекты, которые необходимы для использования тех объектов, которые отсутствуют в этой таблице.

Приоритет	Используется для
debug	Отладочные сообщения, которые дадут как можно больше информации о работе сервиса.
info	Информационные сообщения о нормальной работе сервиса.
notice	Используется для информационных сообщений об элементах, которые позже могут стать проблемой.
warning / warn	Что-то не оптимальное, но ошибки пока нет.
err /error	Произошла некритическая ошибка.
crit	Произошла критическая ошибка.
alert	Используется, когда сервис перестал быть доступен.
emerg / panic	Сообщение генерируется, когда доступность сервиса прекращается.

Когда используется определенный приоритет, все сообщения с этим приоритетом и выше логируются в соответствии со спецификациями, используемыми в этом конкретном правиле. Если вам необходимо детально настроить логирование, когда сообщения с разными приоритетами отправляются в разные файлы, вы можете указать приоритет со знаком равенства (=) перед ним, как в следующем файле конфигурации, который будет отправлять все отладочные сообщения cron в файл с именем /var/log/cron.debug

Обратите внимание на использование дефиса (-) перед именем файла, который гарантирует, что сообщения буферизуются и не записываются немедленно на диск (что хорошо для производительности диска)

Нет необходимости учить наизусть названия rsyslogd  объектов и приоритетов. Все они перечислены в man 5 rsyslog.conf.
Упражнение 2. Изменение правил в rsyslog.confyum install -y httpd

ErrorLog    syslog:local1

systemctl restart httpd

systemctl restart httpdecho «*.debug /var/log/messages/messages-debug» > /etc/rsyslogd/debug.confsystemctl restart rsyslogdtail -f /var/log/messages-debuglogger -p daemon.debug «Daemon Debug Message»

8.1. Утилита lsof

С помощью утилиты вы можете получить список открытых файлов.

При использовании утилиты без параметров будет выводиться список, содержащий все открытые файлы. В данном списке вы можете обнаружить строку команды (в данном случае это команда init), идентификатор созданного процесса в столбце PID (1), а также имя пользователя (root), с привилегиями которого была открыта корневая директория и файл . Данные из столбца FD (содержащего информацию о дескрипторе файла) говорят о том, что директория / являлась как корневой директорией (rtd), так и текущей рабочей директорией (cwd) при исполнении команды /sbin/init. В столбце FD может содержаться строка , указывающая на то, что директория является корневой директорией, строка , указывающая на то, что директория является текущей рабочей директорией и строка , указывающая не то, что открыт файл (включая файлы с данными и кодом).

root@debian7:~# lsof | head -4
COMMAND PID  TID   USER   FD    TYPE     DEVICE SIZE/OFF      NODE NAME
init      1        root  cwd     DIR      254,0     4096         2 /
init      1        root  rtd     DIR      254,0     4096         2 /
init      1        root  txt     REG      254,0    36992    130856 /sbin/init

В остальных случаях в столбце FD приводятся числовые значения дескрипторов с символами, соответствующими режимам открытия файлов, причем символ w соответствует режиму записи данных, r — режиму чтения данных, а u — режиму чтения и записи данных. Вы можете вывести список файлов, открытых в рамках процесса с определенным идентификатором PID, воспользовавшись командой . Для процесса данная команда будет выглядеть следующим образом:

lsof -p 1

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

# df -h | grep sdb
/dev/sdb1                     541M   17M  497M   4% /srv/project33
# vi /srv/project33/busyfile.txt
+  Stopped                 vi /srv/project33/busyfile.txt
# lsof /srv/*
COMMAND  PID USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
vi      3243 root   3u  REG   8,17   4096   12 /srv/project33/.busyfile.txt.swp

А здесь мы видим, что демон открывает несколько файлов журналов для записи (как указано в строке FD).

root@debian7:~# lsof /var/log/*

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
rsyslogd 2013 root    1w   REG  254,0   454297 1308187 /var/log/syslog
rsyslogd 2013 root    2w   REG  254,0   419328 1308189 /var/log/kern.log
rsyslogd 2013 root    5w   REG  254,0   116725 1308200 /var/log/debug
rsyslogd 2013 root    6w   REG  254,0   309847 1308201 /var/log/messages
rsyslogd 2013 root    7w   REG  254,0    17591 1308188 /var/log/daemon.log
rsyslogd 2013 root    8w   REG  254,0   101768 1308186 /var/log/auth.log

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

$ lsof -u paul | grep home
bash    3302 paul  cwd    DIR  253,0     4096  788024 /home/paul
lsof    3329 paul  cwd    DIR  253,0     4096  788024 /home/paul
grep    3330 paul  cwd    DIR  253,0     4096  788024 /home/paul
lsof    3331 paul  cwd    DIR  253,0     4096  788024 /home/paul

Совместно с параметром -u утилиты также может быть использовать символ ^, соответствующий логической операции ‘не’. Исходя из этого, команда для получения информации обо всех открытых файлах, за исключением тех файлов, которые открыты пользователем root, будет выглядеть следующим образом:

lsof -u^root

Output Formats

The parameter enables us to format the output of journalctl query. (or if we are using the long form parameter name) can take a few values.

• show each journal entry in json format in one long line. This is useful when sending logs to a log centralization or analysis service, since it makes them easier to parse.
• will show each log entry in easy-to-read json format.
• will show very detailed information for each journal record with all fields listed.
• shows messages in very short form, without any date/time or source server names.
• shortis the default output format. It shows messages in syslog style.
• is similar to short, but the time stamp second value is shown with precision. This can be useful when you are looking at error messages generated from more than one source, which apparently are throwing error messages at the same time and you want to go to the granular level.

For example, the following command prints logs from the Apache web server in json-pretty format.

$ journalctl -u apache2.service -r -o json-pretty

Here’s a sample of the output. You can see a number of important fields including the user, group, syslog facility, and even the code location that generated the message (if available).

{

"__CURSOR" : "s=c4ee459c883148549d114c566bc0b979;i=12b782;b=6c92864cbcc64a5fabebe04147953894;m=42d22604a2;t=58bc87981a1f5;x=8daf632187

"__REALTIME_TIMESTAMP" : "1561068031812085",

"__MONOTONIC_TIMESTAMP" : "286993548450",

"_BOOT_ID" : "6c92864cbcc64a5fabebe04147953894",

"SYSLOG_FACILITY" : "3",

"_UID" : "0",

"_GID" : "0",

...

"UNIT" : "apache2.service",

"CODE_LINE" : "2039",

"CODE_FUNCTION" : "unit_notify",

"MESSAGE" : "apache2.service: Unit entered failed state.",

"_SOURCE_REALTIME_TIMESTAMP" : "1561068031809136"

}

Расположение логов по умолчанию

Большинство файлов логов Linux находятся в папке /var/log/ вы можете список файлов логов для вашей системы с помощью команды ls:

Ниже мы рассмотрим 20 различных файлов логов Linux, размещенных в каталоге /var/log/. Некоторые из этих логов встречаются только в определенных дистрибутивах, например, dpkg.log встречается только в системах, основанных на Debian.

• /var/log/messages — содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.
• /var/log/dmesg — содержит сообщения, полученные от ядра. Регистрирует много сообщений еще на этапе загрузки, в них отображается информация об аппаратных устройствах, которые инициализируются в процессе загрузки. Можно сказать это еще один лог системы Linux. Количество сообщений в логе ограничено, и когда файл будет переполнен, с каждым новым сообщением старые будут перезаписаны. Вы также можете посмотреть сообщения из этого лога с помощью команды dmseg.
• /var/log/auth.log — содержит информацию об авторизации пользователей в системе, включая пользовательские логины и механизмы аутентификации, которые были использованы.
• /var/log/boot.log — Содержит информацию, которая регистрируется при загрузке системы.
• /var/log/daemon.log — Включает сообщения от различных фоновых демонов
• /var/log/kern.log — Тоже содержит сообщения от ядра, полезны при устранении ошибок пользовательских модулей, встроенных в ядро.
• /var/log/lastlog — Отображает информацию о последней сессии всех пользователей. Это нетекстовый файл, для его просмотра необходимо использовать команду lastlog.
• /var/log/maillog /var/log/mail.log — журналы сервера электронной почты, запущенного в системе.
• /var/log/user.log — Информация из всех журналов на уровне пользователей.
• /var/log/Xorg.x.log — Лог сообщений Х сервера.
• /var/log/alternatives.log — Информация о работе программы update-alternatives. Это символические ссылки на команды или библиотеки по умолчанию.
• /var/log/btmp — лог файл Linux содержит информацию о неудачных попытках входа. Для просмотра файла удобно использовать команду last -f /var/log/btmp
• /var/log/cups — Все сообщения, связанные с печатью и принтерами.
• /var/log/anaconda.log — все сообщения, зарегистрированные при установке сохраняются в этом файле
• /var/log/yum.log — регистрирует всю информацию об установке пакетов с помощью Yum.
• /var/log/cron — Всякий раз когда демон Cron запускает выполнения программы, он записывает отчет и сообщения самой программы в этом файле.
• /var/log/secure — содержит информацию, относящуюся к аутентификации и авторизации. Например, SSHd регистрирует здесь все, в том числе неудачные попытки входа в систему.
• /var/log/wtmp или /var/log/utmp — системные логи Linux, содержат журнал входов пользователей в систему. С помощью команды wtmp вы можете узнать кто и когда вошел в систему.
• /var/log/faillog — лог системы linux, содержит неудачные попытки входа в систему. Используйте команду faillog, чтобы отобразить содержимое этого файла.
• /var/log/mysqld.log — файлы логов Linux от сервера баз данных MySQL.
• /var/log/httpd/ или /var/log/apache2 — лог файлы linux11 веб-сервера Apache. Логи доступа находятся в файле access_log, а ошибок в error_log
• /var/log/lighttpd/ — логи linux веб-сервера lighttpd
• /var/log/conman/ — файлы логов клиента ConMan,
• /var/log/mail/ — в этом каталоге содержатся дополнительные логи почтового сервера
• /var/log/prelink/ — Программа Prelink связывает библиотеки и исполняемые файлы, чтобы ускорить процесс их загрузки. /var/log/prelink/prelink.log содержит информацию о .so файлах, которые были изменены программой.
• /var/log/audit/- Содержит информацию, созданную демоном аудита auditd.
• /var/log/setroubleshoot/ — SE Linux использует демон setroubleshootd (SE Trouble Shoot Daemon) для уведомления о проблемах с безопасностью. В этом журнале находятся сообщения этой программы.
• /var/log/samba/ — содержит информацию и журналы файлового сервера Samba, который используется для подключения к общим папкам Windows.
• /var/log/sa/ — Содержит .cap файлы, собранные пакетом Sysstat.
• /var/log/sssd/ — Используется системным демоном безопасности, который управляет удаленным доступом к каталогам и механизмами аутентификации.

Просмотр загрузочных сообщений

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

Чтобы просмотреть записи журнала, относящиеся к вашей последней загрузке, используйте опцию -b:

journalctl -b

Показаны записи из логов последней загрузки:

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

journalctl -b 3

Как правило, если у вас возникла проблема и вам пришлось перезагрузить компьютер, вам интересна предыдущая последовательность загрузки. Так что это популярная форма команды.

Легко запутаться в последовательности загрузок. Чтобы помочь, мы можем попросить journalctl перечислить загрузки, которые он записал в своём журнале, для этого используйте опцию —list-boots.

journalctl --list-boots

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

sudo journalctl -b bd7cf5063b15440eb5920851af7a5879

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

Основные команды systemd

У есть несколько основных команд, которые быстро запоминаются при постоянном использовании менеджера.

systemctl start name.service — запустить сервис.

• — остановить сервис.
• — перезапустить сервис.
• — узнать статус сервиса.
• — добавить сервис в автозагрузку.
• — удалить сервис из автозагрузки.
• — проверить, находится ли сервис в списке автозагрузки.
• — запретить запуск сервиса.
• — разрешить запуск сервиса.
• — показать службы, которые не запустились.
• — показать страницу руководства сервиса.

systemctl daemon-reload — применить конфигурацию после изменения в описании сервиса.

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

Для удобства можно отсортировать службы по их текущему статусу. Есть четыре флага:

1. — автозагрузка включена;
2. — автозагрузка отключена;
3. — служба скрыта;
4. — служба в автозагрузке, вы не можете ей управлять.

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

Посмотреть полную информацию о незагруженных юнитах:

С помощью также можно увидеть зависимости модуля. Например:

После выполнения команды в терминале отобразится список зависимостей службы :

sshd.service
├─system.slice
└─basic.target
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target

Вы также можете посмотреть свойства любого юнита. Используйте команду:

Вывод:

Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon

Если нужно отобразить одно свойства, добавьте в команду флаг -p с его именем. Например, посмотрите конфликты модуля :

Вывод: