Эта статья призвана познакомить читателя с находящимся в арсенале 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 1758bootctl
А вы знаете, что загрузкой теперь управляет 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Комментарии (29)
Erelecano
21.11.2016 13:10+8Уж лучше бы рассказали людям про journalctl и его полезные фичи, типа journalctl --since yesterday.
POPSuL
22.11.2016 09:00Я тоже с радостью бы почитал про
journalctl.Erelecano
22.11.2016 09:18+2У journalctl есть один минус: к нему надо привыкать. После долгих лет грепанья по логам нужно привыкнуть, что теперь ты можешь сказать «Хочу логи начиная со вчерашнего числа» или «Хочу логи с 15 часов 1 ноября до 16 часов 3 ноября» и их увидеть ничего не грепая, просто одной командой. А так вышел прекрасный инструмент, только за него уже можно Леннарту ставить памятник от благодарных админов.
vitaly_KF
21.11.2016 13:14Офтоп, но может подскажете))
Можно ли получить переменные окружения gui-сессии любого юзера из под рута? Всякие там xdg_* и т.д.
И еще, для чего нужна machinectl?Erelecano
21.11.2016 13:45+1machinectl для работы с контейнерами нужна, входит в пакет systemd-container, чем изрядно об этом намекает.
Подробней https://www.freedesktop.org/software/systemd/man/machinectl.html
ValdikSS
22.11.2016 12:12+2И еще, для чего нужна machinectl?
Хотите вы, например, посмотреть, что там нового и интересного в Fedora 25, качаете cloud-образ, делаете
И у вас запущен контейнер с Fedora 25, с изоляцией, с собственной сетью, причем systemd-networkd сам выберет неиспользуемый диапазон частных IP-адресов, выдаст IP этому контейнеру через DHCP, настроит ему NAT, все сделает.machinectl import-tar fedora25.tar.gz machinectl start fedora25 machinectl login fedora25
Настроили вы Fedora, подняли там, например, прокси, и хотите посмотреть логи. Нет ничего проще! Прямо из хостовой машины их можно увидеть следующим образом:
journalctl -M fedora25 -e
Или, например, перезапустить какой-либо сервис:
systemctl -M fedora25 restart squid
aso
21.11.2016 20:56-2Непонятно, зачем это всё надо.
Заместо известного unix-way — организуем одну огромную оболочку с не особенно прозрачными функциями и «кормящимися» от неё специальными утилитами.
Лучше уж сразу на венду с её гуями и красивыми рюшечками…khim
21.11.2016 23:06+4Заместо известного unix-way
С этого момента — поподробнее.
организуем одну огромную оболочку с не особенно прозрачными функциями и «кормящимися» от неё специальными утилитами.
Никакой «огромной оболочки» я не вижу. Вижу кучу живущих в одном репозитории маленьких утилит. Вижу то, что было во всех версиях Unix с момента его создания.
Если вы видите что-то другое — просьба рассказать где конкретно вы это увидели и когда, в какой конкретно версии Unix оно появилось.
P.S. На всякий случай: GNU/Linux — не является Unix и, соответственно, к Unix-way прямого отношения иметь не может.aso
22.11.2016 07:31-1Множество маленьких, крайне узкоспециализированных, т.е. не универсальных, утилит, заточенных под исполнение узкоспециализированной служебной задачи — загрузки, и больше ни для чего.
Последняя, вообще говоря, должна работать в режиме «отработала — теперь заткнись и отвали».
При этом продемонстрирована тенденция разрастания монстра — он уже не только инит заменяет с башем, но и груб.
Всё нормально, ага-ага.
grossws
22.11.2016 14:55+1Он, скорее всего, не заменяет grub, а даёт более легковесную альтернативу. Как, например, systemd-timesyncd не заменяет ntpd (а является легковесным sntp-клиентом, но не реализует серверную часть). Или systemd-networkd не заменяет networkmanager, wpa_supplicant и кучу другого софта, а даёт маленький сервис конфигурации сети для тех случаев, когда достаточно просто статической или dhcp-конфигурации.
khim
23.11.2016 00:04+2Последняя, вообще говоря, должна работать в режиме «отработала — теперь заткнись и отвали».
Вас сюда, случаем не из 60х занесло? Это в те времена чтобы конфигурацию железа изменить нужно было всё выключать. Уже в 70-е это перестало быть чем-то необычным, а сейчас — система должна как-то понимать, когда её переносят из одного города в другой, когда к ней подключают разные принтеры и флешки — и всё это, вы не поверите, без всякой перезагрузки. Даже на серверах у вас вполне могут возникать новые процессоры и новые устройства (да, конечно, виртуальные — но делает ли это ситуацию проще?).
Так что подход «отработала — теперь заткнись и отвали» не работает. Уже давно не работает. systemd — это попытка выкинуть ту гору костылей, которые были вокруг попытки заставить всё это заработать и сделать всё «по-нормальному».
Заметим что все остальные современные UNIX'ы (всякие Solaris'ы, AIX'ы и MacOS'ы) это всё проделали гораздо раньше. GNU/Linux оставался «последним из могикан».
Erelecano
22.11.2016 00:38+9Непонятно что вы имеете в виду под unix-way. Обычно systemd-хейтеры находятся в возрасте 14-18 лет и настоящих Unix™ в глаза не видели.
1. systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
2. systemd — прямой аналог launchd и smf которые как раз в сертифицированных Unix™ живут.
А все эти визги про «не юниксвейно» раздаются от тех, кто только с мамкиных компов на лоре читал, что так надо попискивать.grossws
22.11.2016 02:08+2systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
Обычно это хорошо чувствуют те, кто мейнтейнил до этого пачку init-скриптов под несколько версий более-менее разных дистрибутивов. Те же зависимости unit'ов просто прекрасны после событий upstart.
Erelecano
22.11.2016 02:26+1После апстарта все что угодно покажется раем, будем честны. Нормальные зависимости были в openrc, но он нигде, кроме Gentoo, не прижился. А upstart был каким-то выкидышем, извините, вроде и хотели сделать лучше, чем было, а вышло черти что и сбоку бантик.
Собственно вы подтверждаете мои слова, что хейтят systemd школьники не работавшие с реальными серверами и не видившие ада старых инит-систем, а мы, с высоты своего опыта, наслаждаемся хорошим инструментом.
aso
22.11.2016 07:38-5Ваше суждение содержит исключительно оценочные, непроверяемые характеристики, т.е. выглядит сектанским по сути.
При этом системд активно раздувается, забирая под себя функциональность не только инита, но и других, сопряжённых вещей — от udev, башинит — уже и до груба.
Это означает непрозрачность и сложность его функционирования — особливо на фоне того, что сопровождается он кучей узкоспециализированных, неуниверсальных утилит со специфическим синтаксисом.
А вообще — главная проблема systemd в том, что его пропихивают везде безальтернативно.Erelecano
22.11.2016 09:05+4Мое мнение — мнение профессионала. А про «сектантство» это вам, как раз, к системд-хейтерам. Сейчас у меня сервера с upstart и systemd, мне нет разницы с чем работать, но с systemd удобней.
Про «забирая функциональность». А вас никто не заставляет ставить те или иные части и их использовать. Вы можете использовать что-то другое. Systemd он модульный. Но вы, как любой хейтер, об этом не знаете, вы ненавидите то, что не видели и в чем не понимаете. Про udev стоит сказать отдельно, что udev разрабатывается авторами systemd и что бы разработчикам было удобней они одно включили в другое, но существует и udev в отрыве от systemd и ничто не мешает его использовать. Но вы и про это не знаете.
Про непрозрачность и сложность вы пишите опять же потому, что вы не пользовались, а просто цитируете чужие слова, тут даже отвечать не буду.
Кто вам сказал про безальтернативность? В Debian/Ubuntu вы можете легким движением руки использовать upstart, sysV, openrc или systemd. А! Вам снова рассказали на сайте хейтеров, а вы сами не знаете о чем пишите. Тогда понятно.
Все ваши «аргументы» представляют из себя набор штампов с сайтов школьников-хейтеров и не соответствуют действительности.grossws
22.11.2016 15:12Про udev стоит сказать отдельно, что udev разрабатывается авторами systemd и что бы разработчикам было удобней они одно включили в другое, но существует и udev в отрыве от systemd и ничто не мешает его использовать. Но вы и про это не знаете.
Меня это поверье (про то, что udev невозможно было собрать без systemd) давно забавляет. Учитывая, что я своими глазами видел, что пакет udev для ubuntu (тогда с upstart'ом) собирался из дерева исходников systemd/udev без каких-либо проблем.
Erelecano
22.11.2016 15:17А хейтеры фактами не владеют, они только читали на ЛОРе и ему подобных ресурсах, что systemd это зло и везде теперь верещат.
А то что можно собрать спокойно udev без systemd это мы с вами знаем, потому что делом занимаемся, а не разводим визги на пустом месте.
menstenebris
22.11.2016 10:17+1Если получится то лучше напишите статью о часто используемых частях systemd. Про journalctl уже попросили. А вот networkd, systemctl, timesyncd, systemd и др можно подробнее рассказать, может после этого хейтеров поменьше будет, а знания у людей побольше.
У меня например большие надежды на networkd потому что каждый раз мучительно вспоминать чем различается настройка сети на centos 5, 6, 7, дебиан и прочих разношерстных дистрибутивах. А если они еще менеджер пакетов реализуют то им вообще памятник надо будет поставить.grossws
22.11.2016 15:13haters gonna hate, тут ничего не поделаешь.
Я недавно посмотрел на networkd на raspberry pi, оказалась очень приятная и более-менее удобная штука.
Erelecano
22.11.2016 15:45То есть рекомендуете на networkd посмотреть? Просто я как-то живу без networkd(хейтер выше от факта, что systemd работает со старыми настройками сети может пойти и поплакать в углу, такое опровержение его бреда про замену всего), но есть где провести эксперименты и глянуть. А не опишите в кратце в чем удобство? Чем оно лучше привычного мне /etc/network/interfaces? На что стоит обратить внимание?
menstenebris
22.11.2016 18:48После слов «привычного мне /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, первый как раз и стартует старые системы управления сетью, от того вам и кажется что он работает со старыми. Второй же напротив имеет свой собственный формат конфигов и с другими не работает.
Radjah
23.11.2016 10:59Перешел на systemd-networkd в jessie, когда хотел воспользоваться целью «systemd-networkd-wait-online» в самописном юните, а оно не сработало как надо.
Интерфейсы само поднимает, конфигурирует по DHCP тоже без сторонней помощи. Имя интерфейса можно задать маской и иметь один юнит на всё, если кроме DHCP ничего не надо для Ethernet.
Synapse-119
22.11.2016 16:06А если они просто новую ось сразу напишут вокруг этого, то из золота отлить?) Надо уметь вовремя останавливаться.
776166
А что, управление загрузкой настолько важный инструмент, который необходим каждый день? :)
khim
systemd (как следует из названия) предназначен для того, чтобы управлять не загрузкой, а системой. И да, это может быть необходимо каждый день. Вернее каждый день, когда возникают проблемы. Если сервер и так работает «как часы», то лезть в него, понятно, не нужно, но если что-то не работает, то…
baldrs
Как и дампы ядра, собственно.