Где хранятся сервисы линукс

Systemd: пишем собственные .service и .target

У меня появился Linux на домашнем компьютере, и я поспешил обжиться в новой ОС. Она была установлена с systemd init process. Это было мое первое знакомство с этим новым инструментом. Cвой ноутбук я использую для каждодневной жизни и для программирования. Мне хотелось включать рабочие программы (Apache2 и MySQL) только на время, пока я их использую, чтобы не тратить впустую ресурсы своего компьютера. Дополнительно, для тестирования я написал bash скрипт, который выгружает содержимое одной из MySQL БД c жесткого диска в ОЗУ (в tmpfs) – так тесты выполняются значительно быстрее. По идее, я мог бы начинать свой рабочий день вот так:

И заканчивать его:

Но мне хотелось сделать вещи “как надо”.

Чего я хотел?

Я хотел достичь 2 целей:

  1. Мне было лень писать 2 команды (запуск apache и запуск mysql), т.к. я знал, что обе программы всегда будут выключаться и включаться синхронно. Хотелось выполнять эту операцию одной командой.
  2. Дело попахивало неприятностями, если компьютер перезагрузится пока моя база данных будет сидеть в tmpfs – все файлы будут потеряны. Конечно, я делал бекапы, но мне опять же было лень восстанавливать их вручную после каждой непредвиденной перезагрузки.

Что я сделал?

В итоге я объединил Apache2 и MySQL в один target. Это позволило запускать оба сервиса одной командой. А свой mysqld-tmpfs скрипт я декларировал в виде сервиса в глазах systemd. Будучи сервисом, я уверен, что systemd выполнит его корректную остановку, если система пойдет на перезагрузку или еще в какую-то нештатную ситуацию, и моя БД без потерь сохранится на жесткий диск.

Что такое service?

Это некоторая программа, которая выполняется в фоне и предоставляет полезную функциональность. К примеру, Apache веб сервер. Сервисы можно запускать и останавливать. Некоторые сервисы могут запускаться и останавливаться автоматически по определенным событиям (загрузка ОС, выгрузка ОС и тп). Так же их можно запускать/останавливать вручную. Сервис декларируется в /etc/systemd/system/my-name.service файлах (с суффиксом “.service”).

Что такое target?

Target в systemd очень похож на runlevel в openRC, но это все-таки разные вещи. Во-первых, target позволяет группировать 1 и более сервисов в единый блок. Группируя сервисы в targets, ими проще управлять. Во-вторых, systemd автоматически включает/выключает targets по событиям. “Включение” target означает включение всех сервисов, которые он объединяет в себе. К примеру, если в systemd настроен target по умолчанию my-favorite.target, то при загрузке системы systemd включит все сервисы, которые задекларированы внутри my-favorite.target. В какой-то момент в консоли можно набрать:

Все сервисы из my-another.target будут включены, и все включенные сервисы не из my-another.target будут выключены. Это очень похоже на переключение runlevel в openRC. Однако, systemd поддерживает включение более чем 1 target. Вот пример:

После выполнения этих команд в системе будет работать объединение сервисов из my-favorite.target и my-another.target.

Как я это сделал?

В итоге у меня получился вот такой mysqld-tmpfs.service файл:

И вот такой programming.target файл:

Какие были проблемы?

При остановке programming.target почему-то нижележащие apache2.service и mysqld.service не останавливались. Почитав как следует man page, я нашел проблему: systemd останавливает сервисы “лениво” — если никто не требует запущенный сервис, и он не был запущен явным образом, а как зависимость для какого-то другого сервиса, то systemd остановит его только при одном из 3 обстоятельств:

  1. Запустится какой-то другой сервис, который в своей декларации указывает, что он конфликтует с нашим сервисом.
  2. Выполнится systemctl isolate some-another.target или systemctl stop this.service.
  3. Наш сервис может запросить в своей декларации останавливать себя не ленивым образом, а активным, добавив вот такую строку в [Unit] секцию: StopWhenUnneeded=true

Декларации “чужих” сервисов можно менять создавая файлы /etc/systemd/system/name-i-alter.service.d/*.conf. Я просто создал /etc/systemd/system/apache2.service/auto-stop.conf и /etc/systemd/system/mysqld.service.d/auto-stop.conf и поместил туда ту строку.

Другая проблема, на которую я, наткнулся была в том, что systemd не очень любит symlinks. Я не большой любитель “загаживать” системные директории типа /etc, /bin, /usr своими локальными продуктами жизнедеятельности, поэтому изначально я попытался свой /etc/systemd/system/mysqld-tmpfs.service сделать symlink на /root/scripts/mysqld-tmpfs.service файл, т.е. хранить сам файл в домашнем каталоге root пользователя. Но systemctl команда отказывалась работать с таким сервисом выдавая малопонятные ошибки. Оказалось, что определенную часть своей внутренней кухни systemd делает именно на symlinks, и ему тогда “трудно” отличать внутреннюю кухню (свои symlinks) от сторонних *.service файлов (если они тоже являются symlinks). Удалив symlink из /etc/systemd/system/mysqld-tmpfs.service и скопировав туда содержимое настоящего файла, я решил эту проблему. Более подробное описание этой проблемы можно прочитать тут: bugzilla.redhat.com/show_bug.cgi?id=955379

Читайте также:  Rdp windows использует порт

Результат

Я достиг своей цели. Начиная рабочий день:

Когда нужно выполнить тесты на своем проекте:

Когда я хочу демонтировать БД из tmpfs в жесткий диск (хотя на практике я так почти не делаю, а просто оставляю БД в tmpfs на целый день, и при выключении systemd за меня запускает демонтировку из tmpfs в жесткий диск):

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

Cheat sheet

Некоторые полезности при работе с systemd:

  • Вызывайте systemctl daemon-reload, если вы изменили декларацию чего-либо (systemd считает файлы декларации заново)
  • systemctl start my-name.(service|target) – запуск сервиса или target
  • systemctl stop my-name.(service|target) – остановка сервиса или target
  • systemctl enable my-name.service – сервисы могут декларировать при каких включенных targets они должны включаться. Для этого используется [Install] секция в файле декларации сервиса. Вы, как сисадмин, имеете власть на установку этого “пожелания” сервиса. Часто сервисы “устанавливаются” в target по умолчанию multi-user.target или в похожее.
  • systemctl disable my-name.service – обратная операция по отношению к enable: деассоциировать связь между my-name.service и targets, которые он запросил в [Install] секции своей декларации.
  • systemctl isolate my.target — включить все сервисы из my.target и выключить все остальные включенные сервисы.
  • systemctl status my-name.(service|target) — узнать статус (запущен/остановлен) у сервиса или target.

Надеюсь, эта статья кому-то поможет при осваивании systemd. Я попытался сделать ее компактной, и если упустил из внимания какие-то дополнительные вопросы, спрашивайте в комментариях!

Источник

Управление сервисами в Linux. Команда systemctl

Что такое сервисы в Linux

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

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

Чаще всего в Linux дистрибутивах для инициализации сервисов используется демон Systemd. К Systemd-дистрибутивам относятся Ubuntu, Debian, Linux Mint, Fedora, openSUSE, Solus и другие.

Есть дистрибутивы, которые не используют Systemd. Вместо Systemd могут использоваться такие системы инициализации, как Upstart, SysV.

В качестве примеров сервисов можно привести: веб-сервер Apache, Network Manager, файрвол Ufw и другие.

Для управления сервисами (Systemd) используется утилита systemctl . Ниже мы рассмотрим основные команды данной утилиты.

Список сервисов

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

Данная команда пробегает по алфавитному списку всех доступных сервисов и выполняет для них команду status.

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

  • [ + ] — запущенный сервис.
  • [ — ] — остановленный сервис.
  • [ ? ] — для данного сервиса отсутствует команда status.

Запуск сервиса

Для запуска сервиса используется команда systemctl start имя_сервиса

Останов сервиса

Для остановки сервиса используется команда systemctl stop имя_сервиса

Перезапуск сервиса

Перезапуск сервиса выполняется командой systemctl restart имя_сервиса

Обычно перезапуск конкретного сервиса требуется, когда были изменены настройки данного сервиса.

Некоторые сервисы поддерживают «мягкую» перезагрузку. В этом случае сервис считывает связанные с ним файлы конфигурации, но не прерывает процесс сервиса. Для выполнения «мягкой» перезагрузки используется команда systemctl reload имя_сервиса . Не все сервисы поддерживают «мягкую» перезагрузку. Если она не поддерживается, то появится сообщение вида: Failed to reload ufw.service: Job type reload is not applicable for unit ufw.service.

Автозагрузка сервисов

Чтобы сервис стартовал (загружался) при запуске системы, его нужно включить в список автозагрузки. Для этого используется команда systemctl enable имя_сервиса

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

Чтобы удалить сервис из автозагрузки, используется команда systemctl disable имя_сервиса

Статус сервиса

Для вывода информации (статуса) сервиса используется команда systemctl status имя_сервиса

Чтобы проверить, запущен ли в данный момент сервис, используется команда systemctl is-active имя_сервиса

Чтобы проверить, включен ли сервис для автозапуска при загрузке системы, используется команда systemctl is-enabled имя_сервиса

Заключение

Мы рассмотрели наиболее часто используемые команды утилиты systemctl. Полный список команд и опций утилиты systemctl можно получить, выполнив:

Источник

Где в системах с systemd лежат файлы конфигурации сети и прочих сервисов?

В дистрибутиве который у меня стоял раньше, сеть настраивалась в файле /etc/network/interfaces, всё понятно и красиво, как во всех гайдах в интернете. Но вот сейчас я поставил минт, и смотрю что в этом файле кроме локальной петли ничего нету. Я сразу подумал, как же тогда интерфейс при запуске сам поднялся то, если там не прописано чтобы он поднимался, там вообще ничего нет. Потом ещё заметил ненормальные названия интерфейсов и пошел гуглить. Из нагугленного понял, что виновник всей этой вакханалии и хаоса некий systemd, который кроме своей задачи запуска системы позволяет себе ещё что-то делать. Ну полез я в папку /etc/systemd/network, а там пусто. Ну и где мне теперь искать куда настройки сети прописаны? Гугл выдет только стандартный путь как в нормальных дистрибутивах.

Читайте также:  Copy from linux to windows share

mint на базе убунты а там netplan.io запилили вроде

cast intelfx

И как уже им пользоваться? Зачем они вообще всё это делают? Всё же прекрасно работало.

Ну и что это? Это же управление нетворк менеджером из терминала. Я и так в нетворк менеджере могу всё прописать. Мне надо знать где сами конфиги лежат в минте этом, и зачем оно так работает.

как во всех гайдах в интернете
Потом ещё заметил ненормальные названия интерфейсов
некий systemd

Ты к нам из 2013го?

Ну и где мне теперь искать куда настройки сети прописаны?

Читай в документации к своему дистрибутиву. В линуксе есть несколько способов настройки сети — interfaces, network manager, networkd etc. Настраиваются они все по разному.

0 Имеем подсказку nmcli c s

1 Читаем man nmcli , в секции SEE ALSO находим nm-settings(5)

2 Внимательно читаем nm-settings(5)

3 Обращаем внимание в секции FILES на

/etc/NetworkManager/system-connections or distro plugin-specific location

5 Настраиваем сеть.

Так зачем мне нетворк менеджер? Я и так могу в нетворк менеджере натыкать. Мне нужен сам файл где эти все настройки прописаны.

Ну так в минте этом только и в графической оболочке через нетворк менеджер и настраивается. Понаделали мусора какого-то, что теперь ничего не работает, ну за-то стильно, модно, молодёжно.

Имена интерфейсов можно назначать через правила udev привязав конкретное имя к конкретному MAC.
при этом само имя может быть любым.

Хорошо, давай вместе.

Покажи вывод nmcli c s

Покажи вывод ls -l /etc/NetworkManager/system-connections/

А можно сделать чтобы всё по человечески было как раньше?

Ну так в минте этом только и в графической оболочке через нетворк менеджер и настраивается

Графические оболочки есть не только у NM. Но, если в минте действительно по умолчанию используется NM (что может быть не так, так как в первом же коммите сказали про убунтовский netplan), то и смотри в его файлы настройки, в чём проблема.

У всех всё работает.

Ну и что это такое? Файл с настройками интерфейса не так должен выглядеть.

ПРОБЛЕМА В ТОМ ЧТО Я НЕ МОГУ НАЙТИ ФАЙЛЫ НАСТРОЙКИ Ну зачем это всё? Кому от этого лучше стало?

Оно включено не во всех дистрибутивах с systemd

Смотрю в 18 убунте: Файл interfaces есть, то есть можно выключить нэтворк-манагер и прописать в него всё по-старинке. Разве нет?

Файл конфигурации соединения для NetworkManager

Файл с настройками интерфейса не так должен выглядеть.

А как должен? Сейчас такие времена, что в одном дистрибутиве могут поддерживаться и ifupdown и systemd-networkd и netplan и NetworkManager

ПРОБЛЕМА В ТОМ ЧТО Я НЕ МОГУ НАЙТИ ФАЙЛЫ НАСТРОЙКИ

Затем, что сейчас не 1999, а 2019. С одной стороны, ноутбуки ­— тут ноут может быть подключен по проводу, там по одной вайфай сети, тут по другой, а где-то вообще через usb-модем с мобильным инетом, interfaces тут сильно не в тему. С другой стороны, контейнеры, облака и прочая, где часто требуется централизованное управление большим количеством сетевых настроек, там и interfaces не в тему, да и голый NM не годится, отсюда всякие netplan/networkd.

То, что вы настраивали а etc network interfaces это одно, это конфигурационный файл для сервиса networking.

Настройки networkmanager это вообще другое, файл interfaces networkmanager не читает и не использует.

Более того настраивать интерфейсы одновременно в etc network interfaces и networkmanager нельзя.

Где networkmanager хранит свои настройки смотрите в его документации.

Фактически на основе файла etc network interfaces вызываются скрипты, в которых вызываются консольные утилиты iproute2, а ранее ifconfig.

Даже сейчас в Ubuntu с нетплан вы можете прописать настройки сети в файле interfaces.

в одном дистрибутиве могут поддерживаться и ifupdown и systemd-networkd и netplan и NetworkManager

NM при этом может ещё поддерживать старую редхатовскую ifcfg схему через плагин ifcfg-rh 🙂

Файлы настройки чего, какого сервиса?

У Нетворк манагер свои файлы и их не надо руками трогать, у нетворкинг — свои.

Откройте документацию по нетворкманагер и документацию по убунту и прочтите как настраивается сеть.

Но чтобы пользоваться файлом interfaces надо как-то удалить все настройки из всех этих менеджеров.

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

В разных дистрибутивах вообще свои файлы настройки сети, так было пока все не стали переходить на система.

Можете посмотреть настройки сети в генту с опенрс, слакваре.

Структура файла настроек сети зависит от сервиса, который управляет сетью в дистрибутиве.

Читайте также:  Как убрать виджеты с рабочего стола windows 10

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

Их можно отключить. Почитай как в системд включать и отключать сервисы (юниты).

Ок. И ради чего весь этот цирк сделали?

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

Но чтобы пользоваться файлом interfaces надо как-то удалить все настройки из всех этих менеджеров.

У меня Debian Buster и networkmanager просто не поставлен, или поставлен и тут же удалён обратно. В общем не чисти их конфиги, просто удали не нужные сервисы.

И ради чего весь этот цирк сделали?

Ради того чтобы затруднить создание дистров отличных от RedHat, который являясь лидером разработки systemd через него будет контролировать развитие конкурирующих проектов.

Ну так ты скажешь мне, недоумку, зачем?

Ну как, тебе как дистростроителю не нравится уже что-то существующее, ты хочешь что-то новое, со своим видением.

Ты пишешь свою вещь и она постепенно едет в продакшн в твоём дистрибутиве.

Откуда по твоему появился systemd, pulseaudio, cinnamon, mate.

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

Но чтобы пользоваться файлом interfaces надо как-то удалить все настройки из всех этих менеджеров.

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

Скорее всего, в mint сеть обслуживают ifupdown и NetworkManager.

  • смотрим, что за файлы в каталоге /etc/netplan и их содержимое
  • проверяем systemd-networkd networkctl status
  • проверяем как стартовала сеть systemctl status networking.service
  • проверяем systemctl status network-manager.service
  • проверим разрешённость NetworkManager nmcli n
  • посмотрим, какими интерфейсами управляет NetworkManager nmcli d s

Проанализировав состояние, можем настраивать /etc/network/interfaces, отключать ненужные сервисы и т.д.

Мне надо знать где сами конфиги лежат

И что ты будешь делать с этим знанием?

В убунтах уже давно, по умолчанию, netplan. Открываешь /etc/netplan, там файл конфига в формате yaml, что то типа:

Всё было включено, нетворк менеджер управлял интерфейсами, всё остановил, а сеть работает дальше.

Пропишу в конфиги то что мне нужно.

Ради того чтобы затруднить создание дистров отличных от RedHat, который являясь лидером разработки systemd через него будет контролировать развитие конкурирующих проектов.

1. Red Hat пилит systemd и не только для своих нужд. 2. Компания делится своими разработками с сообществом. 3. Разработчики дистров сами решают стоит ли им использовать эти наработки. 4. Не хотите использовать systemd, берите что-то другое. Сами его поддерживаете и обеспечивайте его интеграцию с другими проектами.

Все легко и просто.

Нетпалм у меня управляется нетворк менеджером, я отключил его, но сеть всеравно работает дальше. Что за сатанизм то? Есть ещё что-то на чём сеть может висеть?

Судя по всему, сеть настроил NetworkManager, смотри nmcli -t c s Проводное\ соединение\ 1

Походу так и есть. Я затупил, сеть же и не должна была падать после остановки всех служб, ведь они просто один раз настройки указывают для интерфейсов. Вырубил всё и после этого кабель вытянул, сеть поднялась после запуска нетворк менеджера. Но странно почему так, ведь на другом дистрибутиве у меня сеть падала когда нетворкинг вырубаешь, а тут пашет, без всего.

Немного не по теме. Пока разбирался с systemd увидел там вот эту вот забавную фигню gvfs-metadata.service, это что анальные зонды от разрабов убунты?

Если тебе не нужно ничего такого, что нельзя сделать через nmcli, то и настраивай через nmcli без прописывания в конфиги.

Да это дрочево какое-то. Намного проще же просто в конфиг прописать. Как например в этом nmcli pppoe настроить?

Обычно так говорят виндо- и макоюзеры о любом командно-строчном интерфейсе и любых конфигах.

Намного проще же просто в конфиг прописать.

Ага, только сначала надо как минимум выяснить, где он находится.

Как например в этом nmcli pppoe настроить?

Не знаю, я вообще pppoe настраивал один раз в жизни свыше 10 лет назад. Попробуй посмотреть man nmcli-examples .

ты думаешь networkmanager VS netplan — нет же, оно всё работает совместно (надеюсь и не поломается, потому как чинить никто[может я ошибаюсь?] не умеет).

виновник всей этой вакханалии и хаоса некий systemd, который кроме своей задачи запуска системы позволяет себе ещё что-то делать

И ещё детей ест.

gvfs-metadata.service, это что анальные зонды от разрабов убунты

Нет. Это от рептилоидов-жидомасонов. Они прописывают себя в BIOS и потом сразу в прошивку сетевой карты твоего роутера. Так что всё, ты под колпаком, можешь уже не дёргаться.

> ПРОБЛЕМА В ТОМ ЧТО Я НЕ МОГУ НАЙТИ ФАЙЛЫ НАСТРОЙКИ

Теперь реестр. Если хочешь без реестра/systemd, используй Devuan, Knoppix или PClinuxOS

Источник

Оцените статью