company_banner

Пять инструментов systemd, которые стоит начать использовать прямо сейчас

Автор оригинала: Paul Brown
  • Перевод

Эта статья призвана познакомить читателя с находящимся в арсенале systemd набором инструментов.


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


Итак, начнем!


coredumpctl


Этот инструмент, как услужливо подсказывает его имя, используется для получения дампов памяти из журнала systemd.


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



Рис. 1. coredumpctl выводит список всех дампов памяти, зарегистрированных в журнале


Выполнив coredumpctl dump filter, можно получить более подробную информацию о последнем подходящем под фильтр дампе:


coredumpctl dump 1758

Эта команда выведет все детали последнего дампа с PID 1758. А поскольку журнал systemd охватывает более одной сессии (мой, например, начинается с мая), в нем могут оказаться несколько не связанных друг с другом дампов от процессов с одинаковым PID.



Рис. 2. Модификатор dump позволяет получить более подробную информацию о дампе памяти


Также есть возможность установить фильтр по имени исполняемого файла:


coredumpctl dump chrome

Как и в случае с PID, эта команда выведет информацию только о последнем дампе, поскольку в большинстве случаев нужен именно он.


В фильтре дампа памяти может использоваться PID, имя исполняемого файла, путь, который должен содержать как минимум одну косую черту (например, /usr/bin/name_of_executable), а также один или несколько общих предикатов (general predicates) journalctl. Последний вариант показан в следующем примере:


coredumpctl dump _PID=1758

Эта команда по сути идентична coredumpctl dump 1758. А вот более интересный пример использования предикатов journalctl, где нас интересует timestamp:


coredumpctl dump _SOURCE_REALTIME_TIMESTAMP=1463932674907840

Список предикатов journalctl можно найти в разделе JOURNAL FIELDS файла документации man systemd.directives.


Помимо dump у сoredumpctl есть и другие опции. Для тех, кто хочет сразу начать отладку, следующая команда не только выведет всю информацию о дампе, но и откроет GNU debugger (gdb):


coredumpctl gdb 1758

bootctl


А вы знаете, что загрузкой теперь управляет systemd-boot, а не GRUB? Да, это очередная функция, которую подмял под себя, кажется, уже не способный остановиться systemd. Правда, это пока касается только систем с UEFI.


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


(Если вы новичок в Linux, не пугайтесь. Вам, скорее всего, не придется делать ничего из представленного в данном разделе. Об этом позаботится ваш дистрибутив. Все, что здесь написано, в первую очередь предназначено для энтузиастов абсолютного контроля (например, пользователей Arch Linux). Эти люди не могут спать спокойно, пока в их системе остался хотя бы один параметр, который они не пробовали подкрутить.)


Для работы с bootctl нужны права суперпользователя, поэтому обращаться с этим инструментом нужно уважительно. Одно неосторожное движение — и ваша система перестанет загружаться.


Один из самых безобидных режимов bootctl — проверка статуса загрузки. Если /boot не указывает на раздел FAT EFI напрямую, нужно вручную с помощью опции --path= указать путь к загрузочному разделу EFI. Вот как выглядит команда для моей openSUSE:


bootctl --path=/boot/efi

Результатом будет список всех опций загрузки и соответствующих им переменных. Рисунок 3 показывает вывод команды на моей системе. Это поведение по умолчанию. Полная версия команды выглядит так: bootctl --path=/boot/efi status.



Рис. 3. Инструмент bootctl позволяет просматривать и изменять настройки программы управления загрузкой


В выводе команды можно найти опции загрузки и расположение бинарного файла загрузчика (ESP).


Измененная конфигурация загрузки устанавливается с помощью команды:


bootctl --path=/boot/path/to/efi install

Эта команда также сгенерирует бинарный файл systemd-boot, сохранит его в boot/path/to/efi/EFI/Boot и добавит соответствующий вызов в верхнюю часть списка приоритета загрузки.


Чтобы обновить systemd-boot, выполните:


bootctl --path=/boot/path/to/efi update

Для удаления systemd-boot из раздела EFI используйте:


bootctl --path=/boot/path/to/efi remove

Будьте осторожны с последней командой.


systemd-cgtop, systemctl и systemd-cgls


Если классический top позволяет найти процессы, больше других нагружающие CPU и активнее потребляющие память, systemd-cgtop делает то же самое для контрольных групп (cgroups).


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


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


Взгляните на рисунок 4, где изображен пример нормально работающей системы. Никто не злоупотребляет ресурсами, и числового обозначения в строке с итогами удостоились только общие показатели активности всех групп системы. При этом я мог бы избавиться, например, от auditd, веди он себя неподобающим образом. И поскольку система без этого сервиса не остановится, так и сделаю:


systemctl kill auditd.service

И… та-дам! Его больше нет!



Рис. 4 systemd-cgtop сообщает о поведении cgroups


В данном случае у auditd.service были две связанные с ним задачи, но их могут быть сотни, особенно у групп, используемых для конечных пользователей, поэтому systemctl очень удобен для работы с cgroups.


Кстати, чтобы посмотреть, какие процессы связаны с той или иной cgroup, попробуйте команду systemd-cgls /cgroup.name


Например:


systemd-cgls /system.slice/NetworkManager.service

И вы увидите все процессы, работающие в подгруппе NetworkManager.


Заключение


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


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


man systemd.index

Creative Commons Zero

Southbridge
Обеспечиваем стабильную работу highload-проектов

Похожие публикации

Комментарии 30

    +2
    А что, управление загрузкой настолько важный инструмент, который необходим каждый день? :)
      +1
      systemd (как следует из названия) предназначен для того, чтобы управлять не загрузкой, а системой. И да, это может быть необходимо каждый день. Вернее каждый день, когда возникают проблемы. Если сервер и так работает «как часы», то лезть в него, понятно, не нужно, но если что-то не работает, то…
        0
        Как и дампы ядра, собственно.
        +8
        Уж лучше бы рассказали людям про journalctl и его полезные фичи, типа journalctl --since yesterday.
          0

          Я тоже с радостью бы почитал про journalctl.

            +2
            У journalctl есть один минус: к нему надо привыкать. После долгих лет грепанья по логам нужно привыкнуть, что теперь ты можешь сказать «Хочу логи начиная со вчерашнего числа» или «Хочу логи с 15 часов 1 ноября до 16 часов 3 ноября» и их увидеть ничего не грепая, просто одной командой. А так вышел прекрасный инструмент, только за него уже можно Леннарту ставить памятник от благодарных админов.
            0
            Расскажем, ждите новых публикаций!
              0
              Как и обещали: https://habrahabr.ru/company/centosadmin/blog/317182/
            0
            Офтоп, но может подскажете))

            Можно ли получить переменные окружения gui-сессии любого юзера из под рута? Всякие там xdg_* и т.д.

            И еще, для чего нужна machinectl?
              +1
              machinectl для работы с контейнерами нужна, входит в пакет systemd-container, чем изрядно об этом намекает.
              Подробней https://www.freedesktop.org/software/systemd/man/machinectl.html
                +2
                И еще, для чего нужна machinectl?
                Хотите вы, например, посмотреть, что там нового и интересного в Fedora 25, качаете cloud-образ, делаете
                machinectl import-tar fedora25.tar.gz
                machinectl start fedora25
                machinectl login fedora25
                И у вас запущен контейнер с Fedora 25, с изоляцией, с собственной сетью, причем systemd-networkd сам выберет неиспользуемый диапазон частных IP-адресов, выдаст IP этому контейнеру через DHCP, настроит ему NAT, все сделает.
                Настроили вы Fedora, подняли там, например, прокси, и хотите посмотреть логи. Нет ничего проще! Прямо из хостовой машины их можно увидеть следующим образом:
                journalctl -M fedora25 -e

                Или, например, перезапустить какой-либо сервис:
                systemctl -M fedora25 restart squid
                –2
                Непонятно, зачем это всё надо.
                Заместо известного unix-way — организуем одну огромную оболочку с не особенно прозрачными функциями и «кормящимися» от неё специальными утилитами.
                Лучше уж сразу на венду с её гуями и красивыми рюшечками…
                  +4
                  Заместо известного unix-way
                  С этого момента — поподробнее.

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

                  Если вы видите что-то другое — просьба рассказать где конкретно вы это увидели и когда, в какой конкретно версии Unix оно появилось.

                  P.S. На всякий случай: GNU/Linux — не является Unix и, соответственно, к Unix-way прямого отношения иметь не может.
                    –1
                    Множество маленьких, крайне узкоспециализированных, т.е. не универсальных, утилит, заточенных под исполнение узкоспециализированной служебной задачи — загрузки, и больше ни для чего.
                    Последняя, вообще говоря, должна работать в режиме «отработала — теперь заткнись и отвали».
                    При этом продемонстрирована тенденция разрастания монстра — он уже не только инит заменяет с башем, но и груб.
                    Всё нормально, ага-ага.
                      +1

                      Он, скорее всего, не заменяет grub, а даёт более легковесную альтернативу. Как, например, systemd-timesyncd не заменяет ntpd (а является легковесным sntp-клиентом, но не реализует серверную часть). Или systemd-networkd не заменяет networkmanager, wpa_supplicant и кучу другого софта, а даёт маленький сервис конфигурации сети для тех случаев, когда достаточно просто статической или dhcp-конфигурации.

                        +2
                        Последняя, вообще говоря, должна работать в режиме «отработала — теперь заткнись и отвали».
                        Вас сюда, случаем не из 60х занесло? Это в те времена чтобы конфигурацию железа изменить нужно было всё выключать. Уже в 70-е это перестало быть чем-то необычным, а сейчас — система должна как-то понимать, когда её переносят из одного города в другой, когда к ней подключают разные принтеры и флешки — и всё это, вы не поверите, без всякой перезагрузки. Даже на серверах у вас вполне могут возникать новые процессоры и новые устройства (да, конечно, виртуальные — но делает ли это ситуацию проще?).

                        Так что подход «отработала — теперь заткнись и отвали» не работает. Уже давно не работает. systemd — это попытка выкинуть ту гору костылей, которые были вокруг попытки заставить всё это заработать и сделать всё «по-нормальному».

                        Заметим что все остальные современные UNIX'ы (всякие Solaris'ы, AIX'ы и MacOS'ы) это всё проделали гораздо раньше. GNU/Linux оставался «последним из могикан».
                      +9
                      Непонятно что вы имеете в виду под unix-way. Обычно systemd-хейтеры находятся в возрасте 14-18 лет и настоящих Unix™ в глаза не видели.
                      1. systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
                      2. systemd — прямой аналог launchd и smf которые как раз в сертифицированных Unix™ живут.

                      А все эти визги про «не юниксвейно» раздаются от тех, кто только с мамкиных компов на лоре читал, что так надо попискивать.
                        +2
                        systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)

                        Обычно это хорошо чувствуют те, кто мейнтейнил до этого пачку init-скриптов под несколько версий более-менее разных дистрибутивов. Те же зависимости unit'ов просто прекрасны после событий upstart.

                          +1
                          После апстарта все что угодно покажется раем, будем честны. Нормальные зависимости были в openrc, но он нигде, кроме Gentoo, не прижился. А upstart был каким-то выкидышем, извините, вроде и хотели сделать лучше, чем было, а вышло черти что и сбоку бантик.

                          Собственно вы подтверждаете мои слова, что хейтят systemd школьники не работавшие с реальными серверами и не видившие ада старых инит-систем, а мы, с высоты своего опыта, наслаждаемся хорошим инструментом.
                          –5
                          Ваше суждение содержит исключительно оценочные, непроверяемые характеристики, т.е. выглядит сектанским по сути.
                          При этом системд активно раздувается, забирая под себя функциональность не только инита, но и других, сопряжённых вещей — от udev, башинит — уже и до груба.
                          Это означает непрозрачность и сложность его функционирования — особливо на фоне того, что сопровождается он кучей узкоспециализированных, неуниверсальных утилит со специфическим синтаксисом.

                          А вообще — главная проблема systemd в том, что его пропихивают везде безальтернативно.
                            +4
                            Мое мнение — мнение профессионала. А про «сектантство» это вам, как раз, к системд-хейтерам. Сейчас у меня сервера с upstart и systemd, мне нет разницы с чем работать, но с systemd удобней.
                            Про «забирая функциональность». А вас никто не заставляет ставить те или иные части и их использовать. Вы можете использовать что-то другое. Systemd он модульный. Но вы, как любой хейтер, об этом не знаете, вы ненавидите то, что не видели и в чем не понимаете. Про udev стоит сказать отдельно, что udev разрабатывается авторами systemd и что бы разработчикам было удобней они одно включили в другое, но существует и udev в отрыве от systemd и ничто не мешает его использовать. Но вы и про это не знаете.

                            Про непрозрачность и сложность вы пишите опять же потому, что вы не пользовались, а просто цитируете чужие слова, тут даже отвечать не буду.

                            Кто вам сказал про безальтернативность? В Debian/Ubuntu вы можете легким движением руки использовать upstart, sysV, openrc или systemd. А! Вам снова рассказали на сайте хейтеров, а вы сами не знаете о чем пишите. Тогда понятно.

                            Все ваши «аргументы» представляют из себя набор штампов с сайтов школьников-хейтеров и не соответствуют действительности.
                              0
                              Про udev стоит сказать отдельно, что udev разрабатывается авторами systemd и что бы разработчикам было удобней они одно включили в другое, но существует и udev в отрыве от systemd и ничто не мешает его использовать. Но вы и про это не знаете.

                              Меня это поверье (про то, что udev невозможно было собрать без systemd) давно забавляет. Учитывая, что я своими глазами видел, что пакет udev для ubuntu (тогда с upstart'ом) собирался из дерева исходников systemd/udev без каких-либо проблем.

                                0
                                А хейтеры фактами не владеют, они только читали на ЛОРе и ему подобных ресурсах, что systemd это зло и везде теперь верещат.
                                А то что можно собрать спокойно udev без systemd это мы с вами знаем, потому что делом занимаемся, а не разводим визги на пустом месте.
                        +1
                        Если получится то лучше напишите статью о часто используемых частях systemd. Про journalctl уже попросили. А вот networkd, systemctl, timesyncd, systemd и др можно подробнее рассказать, может после этого хейтеров поменьше будет, а знания у людей побольше.
                        У меня например большие надежды на networkd потому что каждый раз мучительно вспоминать чем различается настройка сети на centos 5, 6, 7, дебиан и прочих разношерстных дистрибутивах. А если они еще менеджер пакетов реализуют то им вообще памятник надо будет поставить.
                          0

                          haters gonna hate, тут ничего не поделаешь.


                          Я недавно посмотрел на networkd на raspberry pi, оказалась очень приятная и более-менее удобная штука.

                            0
                            То есть рекомендуете на networkd посмотреть? Просто я как-то живу без networkd(хейтер выше от факта, что systemd работает со старыми настройками сети может пойти и поплакать в углу, такое опровержение его бреда про замену всего), но есть где провести эксперименты и глянуть. А не опишите в кратце в чем удобство? Чем оно лучше привычного мне /etc/network/interfaces? На что стоит обратить внимание?
                              0
                              После слов «привычного мне /etc/network/interfaces» сразу понятно что у вас дебианоподобный дистрибутив и вы думаете что так же везде. А некоторые задают вопросы в стиле «I work now with Centos 5.4 and I would like configure my Ethernet, but I can't find the /etc/network/interfaces. Have you andy idea?» ( https://www.centos.org/forums/viewtopic.php?t=26110 ). То что вы живете прекрасно без развития это понятно. Еще каких то сто лет назад люди прекрасно вообще без компьютеров жили и не надо вот это всего было. Вы так же можете сюда добавить сентенции «не трогай пока работает» и «они бы еще ОС написали». Так же вы кажется перепутали systemd и networkd, первый как раз и стартует старые системы управления сетью, от того вам и кажется что он работает со старыми. Второй же напротив имеет свой собственный формат конфигов и с другими не работает.
                                0
                                Перешел на systemd-networkd в jessie, когда хотел воспользоваться целью «systemd-networkd-wait-online» в самописном юните, а оно не сработало как надо.

                                Интерфейсы само поднимает, конфигурирует по DHCP тоже без сторонней помощи. Имя интерфейса можно задать маской и иметь один юнит на всё, если кроме DHCP ничего не надо для Ethernet.
                              0
                              А если они просто новую ось сразу напишут вокруг этого, то из золота отлить?) Надо уметь вовремя останавливаться.
                              0
                              Вот это всё с какой версии systemd работает? Упоминания в статье не нашел.

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

                              Самое читаемое