Мне нравится systemd.

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

Позвольте мне начать издалека. Будучи молодым, осваивал свою первую операционную систему из мира open source — FreeBSD. Как новичок я не понимал как правильно делать свои стартовые скрипты для не системного софта. С системным софтом во FreeBSD относительно просто. Вам нужен ssh? Укажите sshd_enable=»YES» в /etc/rc.conf и вам будет дано. А как запускать свои программные поделки при старте системы? Мой молодой ум в те времена не нашёл ничего лучше как создавать исполняемый стартовый скрипт в /usr/local/etc/rc.d/ типа так

Если скрипт имеет бит исполняемости и обрабатывает параметры start и stop, то в принципе это работало. Если правильно писать скрипты, используя rc.subr, то можно даже указать какие службы должны быть уже быть запущенными до вашего старта. Самое главное что нужно понять — вам придётся писать shell код для старта вашей программы. Это ни хорошо, ни плохо. Это факт и всё.

После первого знакомства с Linux я реально был напуган её системой инициализации, безгранично царствущей в те времена. 7 уровней ада инициализации от 0 до 6, где 4 уровень не используется. Стартовые скрипты лежат в одном месте, а с помощью симлинков с хитрыми именами в другом месте вы пытаетесь объяснить системе что и когда вы хотите запустить. Имя симлинка несёт не смысловую нагрузку, а функциональную! Имя симлинка начинается с К (для примера K60crond) и это указание убить службу. Имя c буквы S (для примера S40crond) — запустить службу. Числа, следующие перед именем службы задают порядок запуска скриптов. Вы мало того, что опять пишете код запуска и остановки сервиса, но и ещё кувыркаетесь с именами симлинков. Только не говорите мне про утилиты, которые облегчают этот мартышкин труд. Они не облегчают, а скрывают эстетическое несовершенство.

А теперь systemd. Вы не пишите простыни какого-либо кода. Вы не колдуете с именем файла или с именами симлинков на него. Вы просто указываете что запустить и всё.

Со временем ваш стартовый unit изменится и количество строк в нём увеличится. Но это будут строки, которые объясняют системе инициализации systemd ЧТО нужно сделать, а НЕ КАК это делать. Сразу скажу, я не спец по systemd. Он относительно недавно вошёл в нашу жизнь и моё знакомство по серьёзному началось после переключения с upstart на systemd моей рабочей Убунту 15.04. Но не являясь спецом, хотелось бы рассказать о своих мыслях по поводу систем инициализации.

Вот внедрил я с коллегами систему виртуализации на базе ProxmoxVE и программным хранилищем Ceph. Перевели мы свои физические сервера в новый виртуальный мир. Появилась возможность легко сделать виртуальные сервера другим отделам на моём предприятии под их задачи и проекты. И вот первый такой виртуальный сервер поставил жизненный вопрос. Помня прошлый зоопарк из разных версий FreeBSD и дистрибутивов Linux, от которого я избавился, переведя все системы на Ubuntu Server LTS, я оставил за собой все root права внутри гостевой операционной системы. С помощью механизма sudo разрешаю нужные привилегии человеку, который будет курировать уже работу сервисов внутри гостевой ОС. И вот человек ваяет в папке скрипт на Python 3, который сам себе веб-сервер и сам себе аля Zabbix каких-то локальных ресурсов. Человек не задумывается, что в идеале для его самописного скрипта нужно организовать автостарт на сервере. Пара моих обновлений сервера и его перезагрузка наглядно это показали.

Как мне быть как админу? Не являясь автором скрипта и не желая вмешиваться в его судьбу, в системе Init мне необходимо создать свой скрипт-обёртку на sh, в котором я запускаю и останавливаю сторонний для меня питоновский скрипт. Потом должен буду сделать нужные симлинки. Если завтра этот человек скажет мне, что его скрипт дорос до хранения данных мониторинга в базе данных MySQL, то мне нужно организовать загрузку питоновского скрипта-демона ПОСЛЕ сервиса MySQL. В systemd нужно добавить строку After в свой файл unit и указать требуемое, а вот в Init я сомневаюсь что отделался бы одной строкой изменений.

Я благодарен systemd уже за то, что он избавляет меня от программирования в вопросах автостарта. Как админу мне нравится systemd тем, что он единственный на сегодняшний день кто поможет вам со сложными демонами. Если в простом случае демон функционирует как один процесс, всё действительно очень просто. Для остановки демона в своём скрипте вы будете писать что-то типа kill $(cat /var/run/daemon.pid). А если демон работает в сложном сценарии, порождая из разрешённых вами программ другие процессы? Когда вы убиваете основной процесс, он может остановить все свои дочерние процессы, а может и не остановить. Systemd с помощью cgroup единственная сейчас система инициализации, способная остановить демона вне зависимости от того, сколько раз он форкался, и как бы он ни пытался сбежать из-под вашего контроля при помощи двойного форка или форк-бомбардировки. После неудачного stop сложного демона, вы скорее всего сделаете ему kill и потом будете искать в выводе ps зомби-процессы, пытаясь их завершить. Скорее всего всё закончится перезагрузкой всего сервера. А systemctl kill работает чисто и железно.

Кратко хочется подытожить моё мнение о systemd. Спасибо ему за лёгкость и простоту "вмешательства" в операционную систему, абсолютный контроль за демонами. А в будущем, подходя к своим и не своим серверам, спасибо за одноообразие в лице одной системы инициализации — systemd.

---

Изучаем и используем Systemd

Оригинал: Understanding and Using Systemd
Автор: Carla Schroder
Дата публикации: 18 September 2014
Перевод: Н.Ромоданов
Дата перевода: декабрь 2014 г.

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

Ценность systemd является спорной по нескольким причинам: он заменяет то, что, как думают многие пользователи Linux, заменять не требуется, и все гримасы разработчиков systemd не завоевывают сердца и умы. Скорее наоборот, о чем свидетельствует знаменитый блог LKML, в котором Линус Торвальдс отстранил разработчика systemd Кая Зиверса (Kay Sievers) от разработок ядра Linux.

Интересно, когда личности позволяют вставать на пути. Как ни интересно разглагольствовать и отпускать красочные эпитеты, но это к делу не относится. Ибо в течение многих лет системе Linux было достаточно SysVInit и BSD init. Потом появились добавления к менеджерам сервисов, например, такие команды, как service и chkconfig, которые должны были сделать управление сервисами проще, но для меня это было лишь то, что просто нужно было выучить, что не сделало задачи проще, а лишь внесло больше беспорядку.

Затем появились Upstart и systemd со всеми дополнительными примочками для обеспечения совместимости с SysVInit.

Все это замечательно, но надо было умудриться в этом всем этом разобраться. Теперь Upstart вышел в отставку в пользу systemd, и в Ubuntu вы найдете массу библиотек и инструментов для работы с systemd. Просто для интереса посмотрите в Ubuntu список файлов в пакете systemd-services:

$ dpkg -L systemd-services

Для того, чтобы узнать, для чего все это нужно, загляните на страницы man.

Всегда страшно, когда разработчики начинают возиться вокруг ключевых подсистем Linux, поскольку мы просто можем утонуть в том, что нам предлагают. Если нам не нравится конкретная программа, среда рабочего стола или команда и есть несколько альтернатив, то легко воспользоваться чем-то другим. Но основные подсистемы сидят глубоко в ядре, во всевозможных скриптах управления, а также в зависимостях, поэтому их замена — задача нетривиальная.

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

Первые шаги с systemd

Фирма Red Hat является изобретателем и вдохновителем внедрения механизма systemd, поэтому лучшие дистрибутивы для использования этого средства, это — Red Hat Enterprise Linux, клоны RHEL, например, CentOS и Scientific Linux, и, конечно, хорошо известная Fedora Linux, которая всегда поставляется с самыми последними, самыми большими и кровоточащими новинками.

Мои примеры из системы CentOS 7.

Опытные пользователи RH могут в RH 7 по-прежнему пользоваться командами service и chkconfig, но давно уже пора отказаться от них в пользу нативных команд systemd. systemd развивается и команды service и chkconfig не поддерживают нативные сервисы systemd.

Нет нашего любимого файла . Вместо этого, у нас есть каталог /, заполненный символическими ссылками на файлы в каталоге . Скрипты инициализации находятся в каталоге ; для того, чтобы при загрузке системы запустить сервис, его нужно связать с . Когда вы включаете новый сервис, то это для нас делает команда systemctl, как, например, в следующем примере для ClamAV:

# systemctl enable clamd@scan.service ln -s ‘/usr/lib/systemd/system/clamd@scan.service’ ‘/etc/systemd/system/multi-user.target.wants/clamd@scan.service’

Как вы узнаете имя скрипта инициализации и откуда его взять? В Centos7 они добавлены в отдельные пакеты. Многие серверы (например, Apache) нельзя запустить с помощью systemd и для них нет скриптов инициализации systemd. Для ClamAV предлагаются скрипты инициализации как для systemd, как и для SysVInit, поэтому вы можете установить этот пакет любым способом, который вы предпочитаете:

$ yum search clamav clamav-server-sysvinit.noarch clamav-server-systemd.noarch

Так что же внутри этих скриптов инициализации? Мы это можем это увидеть сами:

$ less /usr/lib/systemd/system/clamd@scan.service .include /lib/systemd/system/clamd@.service [Unit] Description = Generic clamav scanner daemon [Install] WantedBy = multi-user.target

Теперь вы можете видеть, как systemctl узнает, где установить символическую ссылку, и в этом скрипте инициализации также указана зависимость от другого сервиса — clamd@.service.

Команда systemctl отображает состояние всех установленных сервисов, у которых есть скрипты инициализации:

$ systemctl list-unit-files —type=service UNIT FILE STATE […] chronyd.service enabled clamd@.service static clamd@scan.service disabled

Для сервиса есть три возможных состояния: включено (enabled), отключено (disabled) и статическое состояние (static). Состояние включено означает, что в каталоге .want есть символическая ссылка. Состояние отключено означает, это не так. Статическое состояние означает, что сервис отсутствует в секции [Install] его скрипта инициализации, поэтому вы не можете ни включить, ни выключить его. Статические сервисы обычно зависят от других сервисов и управление ими осуществляется автоматически. Это можно видеть на примере ClamAV, т. к. сервис clamd@.service зависит от сервиса clamd@scan.service и работает только тогда, когда работает сервис clamd@scan.service.

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

$ systemctl status bluetooth.service bluetooth.service — Bluetooth service Loaded: loaded (/usr/lib.systemd/system/bluetooth.service; enabled) Active: active (running) since Thu 2014-09-14 6:40:11 PDT Main PID: 4964 (bluetoothd) CGroup: /system.slice/bluetooth.service |_4964 /usr/bin/bluetoothd -n

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

Список команд

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

# systemctl start [name.service] # systemctl stop [name.service] # systemctl restart [name.service] # systemctl reload [name.service] $ systemctl status [name.service] # systemctl is-active [name.service] $ systemctl list-units —type service —all

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

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

$ systemctl list-units —type [имя юнита]

Так в чем выигрыш?

По какой-то причине, кажется, что сторонники замены SysVInit одержимы попыткой уменьшить время загрузки. Мои системы с system, такие как CentOS 7, загружаются не намного быстрее, чем прочие. В любом случае, это не то, что меня особенно беспокоит, поскольку в большинстве случаев скорость загрузки измеряется только до появления приглашения для входа в систему, а не тем, как долго система будет запускаться и когда ей можно будет полностью пользоваться. В этом отношении система Microsoft Windows уже давно стала нечестным чемпионом, поскольку приглашение для входа в систему появляется достаточно быстро, а затем требуется еще несколько минут для того, чтобы загрузить и запустить все прочее, что в значительной степени вам не нужно. Как мне кажется, что когда появляется еще один глупый экран с предложением обновления Oracle Java, мне начинает казаться, что это насилие над мною.

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

$ systemd-analyze blame 5.728s firewalld.service 5.111s plymouth-quit-wait.service 4.046s tuned.service 3.550s accounts.daemon.service […]

… и еще несколько десятков программ и сервисов. На сегодня это все. systemd уже очень сложная штука; для того, чтобы узнать больше, используйте другие источники.

---

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

Замечание. Все ниже перечисленные команды надо выполнять из под пользователя root.

Для смены пользователя или получения прав root используйте команды «su -» или «sudo».

Перезагрузка Linux системы.

1. Команда shutdown, с ключом -r.

Команда shutdown является основной командой для управлением остановки или перезагрузки системы linux.

[root@linux ~]# shutdown -r now

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

[root@linux ~]# shutdown -r 10:30 «REBOOT SYSTEM»

2. Команда reboot.

Команда reboot выпоняет все необходимые операции для остановки системы, эта команда может быть вызвана командой shutdown -r, но может использоваться отдельно. Данная команда записывает в журнал логов время остановки системы, уничтожает незавершенные процессы, выполняет системный вызов sync, ждет завершения записи на диск, а только после этого прекращает работу ядра и перезагружает систему Linux.

[root@linux ~]# reboot

3. Команда telinit 7.

С помощю этой команды можно задать демону init перейти на определенный уровень выполнения, а именно цифра 7 говорит о том что нужно прейти на 7-ой уровеь (перезагрузка). Команда telinit не поддерживает задание паузы и вывода предупреждающих сообщений. Обычно используется при проверке изменений внесеных в файл inittab.

[root@linux ~]# telinit 7

Выключение Linux системы.

1. Команда shutdown, с ключом -h.

[root@linux ~]# shutdown -h now

2.

Мне нравится systemd.

Команда halt.

Команда идентична команде reboot по своим действиям, разница в том, что команда halt выключает систему.

[root@linux ~]# halt

3. Используем команду poweroff.

Команда poweroff идентична команде halt, кроме того, что после остановки системы посылается специальный запрос системе управления питанием на отключение питания, что позволяет дистанционно отключать системы.

[root@linux ~]# poweroff

4. Команда telinit 0

Идентична команде telinit 7 только переходит на уровень 0, что означает остановку системы.

[root@linux ~]# telinit 0

Вот и все, рассмотрение основных способов выключение и перезагрузки Linux систем из командной строки завершено.

Как включить программу в автозагрузку или, наоборот, удалить из автозагрузки в CentOS?
Посмотреть список автозагрузки можно при помощи команды:

# /sbin/chkconfig —list

atop 0:off 1:off 2:on 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off httpd 0:off 1:off 2:off 3:on 4:off 5:off 6:off ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off

Отображаются 7 уровней выполнения, которые обозначаются числами от 0 до 6.
Уровень 0 — остановка системы (halt) — работа системы должна быть прекращена;
Уровень 1 — однопользовательский режим работы — система инициализирует минимум служб и даёт единственному пользователю (как правило, суперпользователю) без проведения аутентификации командную строку.

Изучаем и используем Systemd

Как правило, этот режим используется для восстановления системы;
Уровень 2 — многопользовательский режим — пользователи могут работать на разных терминалах, вход в систему с процессом аутентификации;
Уровень 3 — многопользовательский сетевой режим — в отличие от предыдущего уровня, осуществляется настройка сети и запускаются различные сетевые службы;
Уровень 4 — не имеет стандартного толкования и практически не используется;
Уровень 5 — запуск графической подсистемы — по сравнению с уровнем 3 производится также старт графической подсистемы X11, и вход в систему осуществляется уже в графическом режиме;
Уровень 6 — перезагрузка системы — при включении этого режима останавливаются все запущенные программы и производится перезагрузка.

В основном, используются уровни 2, 3, 5.

Добавить процесс в автозагрузку можно командой:

# chkconfig -add nginx

которая автоматически активирует 2, 3, 4, 5 уровни. Также можно указать необходимые уровни:

# chkconfig —level 345 nginx on

Как удалить программу из автозагрузки?

# chkconfig —del nginx

Как добавить службу в автозагрузку?

# chkconfig —add nginx

Запущенные процессы в Linux

Автор: Admin

Дата:2012-10-26

Как узнать список запущенных процессов в Linux?

Процесс — это программа выполняющаяся в системе.

1) В большинстве случаев для исследования процессов в Linux используется команда «ps», которая может выполняться как в текстовом режиме так и иметь графическую оболочку.

#ps ax — отображает полную информацию о процессах

PID    TTY      STAT   TIME COMMAND
    1      ?           Ss     0:03 /sbin/init
17676  ?           Ss     0:00 /usr/sbin/pptpd

По хорошему эта команда, наверное, нам нужна для отслеживания процессов и убития зависших, как по нажатию сочетания клавиш ctrl+alt+delete мы попадаем в диспетчер задав в Виндовсе и можем остановить зависший процесс.

Ее можно применить вместе с grep, для более быстрого поиска нужного нам процесса
# ps ax |  grep pptp
 2036 pts/0    S+     0:00 grep pptp
17676 ?        Ss     0:00 /usr/sbin/pptpd
Здесь он нам нашел наш поиск и сам процесс под номером 17676

А можем воспользоваться уже готовой утилитой поиска процесса
# pgrep -l pp
2111 pptpd

2) Убить процесс нам поможет команда:
# kill 17676 — которая принудительно прекратит его выполнение
# killall pptpd — останавливает процесс по имени

3) Если вам нужно древовидное отображение процессов, то на помощь придет утилита:
# pstree
init —acpid
     —apache2—5*[apache2]
     —atd
     —cron
     —dd
     —freshclam
     —6*[getty]
     —klogd
     —miniserv.pl
     —named—3*[{named}]
     —nmbd
     —pptpd
     —slapd—2*[{slapd}]
     —smbd—smbd
     —sshd—sshd—bash—pstree
     —syslogd
     —udevd
     —xinetd

Здесь, соответственно, видна зависимость процессов друг от друга в древовидном виде.
А более подробную зависимость можно посмотреть если добавить ключ -a
# pstree -a
4) Еще одна очень полезная утилита.
# top — отображение процессов в реальном времени

Tasks:  52 total,   1 running,  51 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us,  0.7%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    247780k total,   242104k used,     5676k free,    64152k buffers
Swap:   465844k total,      184k used,   465660k free,   127556k cached
  PID USER      PR  NI  VIRT  SHR S %CPU  RES %MEM    TIME+  COMMAND
 2094 root      18   0  2304  852 R  0.3 1064  0.4   0:01.05 top
 5549 syslog    15   0  1932  528 S  0.3  680  0.3  49:43.08 syslogd
 5571 root      15   0  1868  440 S  0.3  532  0.2  72:10.96 dd
    1 root      15   0  2840  540 S  0.0 1684  0.7   0:03.12 init
    2 root      12  -5     0    0 S  0.0    0  0.0   0:00.00 kthreadd
Здесь отображается используемая память и процессор, приостановленные и рабочие процессы.

Отсюда можно произвести изменение приоритета процесса или удалить его. Просмотреть состояние процесса (простой, остановленный, зависший и др.)

# gtop — может применяться в графическом режиме.

Другие команды Linux

Так, что бы стало понятно зачем и как можно применять команды в Linux. продемонстирую небольшой скрипт Bash.
Данный скрипт проверяет имеется ли процесс c именем smb и в том случае если его нет происходит его старт.
grep -v grep необходим, что бы исключить сам процесс поиска smb

# vi ps

#!/bin/bash
ps ax | grep -v grep | grep smb
if [ $? -ne 0 ]
        then
/etc/init.d/smb start
        else
echo «демон работает» > /dev/null
fi

Количество просмотров: 22288

© Plutonit.ru — Администрирование, настройка Linux и Windows 2009 — 2018