Оглавление:

- Что такое сервисный файл?

- Быстрый помощник - мини help!

- Как выглядит сервисный файл?

- Взаимодействие с сервисным файлом.

- Параметры сервисного файла, Раздел [Unit].

- Параметры сервисного файла, Раздел [Service].

- Параметры сервисного файла, Раздел [Install].

- Установка мягких и жестких ограничений на различные ресурсы (limit, ulimit).

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

Сервисный файл (service) — это тип юнита (unit) в системе инициализации Systemd, которая используется в большинстве современных дистрибутивов Linux, таких как Ubuntu, CentOS и Debian. Однако, помимо сервисов, в Systemd существуют и другие типы юнитов, такие как target, mount, automount, slice, device, path, scope, snapshot и socket. Эти юниты играют различные роли в системе, обеспечивая её работоспособность и взаимодействие с внешними устройствами, управляя подключениями и состоянием системы.

Юниты — это ключевые компоненты Systemd, которые обеспечивают выполнение различных задач. Например, socket используется для управления сетевыми сокетами, а mount отвечает за монтирование файловых систем. Target помогает организовывать последовательность загрузки системы, а path следит за изменениями в определённых путях файловой системы. Device управляет обнаружением и подключением устройств, а automount автоматически монтирует файловые системы при доступе к ним.

Slice — это тип юнита, который делит ресурсы системы между различными группами процессов, что позволяет управлять их приоритетами и доступом к ресурсам. Scope представляет собой временный юнит, созданный для выполнения задач в определённом контексте. Snapshot используется для создания снимков состояния юнитов в определённый момент времени, что упрощает восстановление системы до предыдущего состояния.

Systemd управляет юнитами на протяжении всего времени работы компьютера — от загрузки до завершения. Процессы запускаются параллельно, что позволяет минимизировать время загрузки системы. Все юниты хранятся в каталоге /etc/systemd/system/, и их управлением занимается команда systemctl, с помощью которой можно запускать, останавливать и перезапускать юниты. Логи юнитов можно просматривать с помощью команды journalctl.

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

**********

РЕКОМЕНДАЦИЯ:

Мы настоятельно рекомендуем запускать все ноды в виде сервисных файлов и сами придерживаемся этого подхода в своих руководствах. Это решение обладает рядом преимуществ:

Фоновый режим работы: Сервисные файлы обеспечивают работу нод без необходимости вашего участия.

Автозапуск при старте системы: Ноды запускаются автоматически вместе с системой, что упрощает их использование.

Простое управление: Команды systemctl позволяют легко запускать, останавливать и перезапускать сервисы.

Краткое пояснение основных терминов:

Юнит/служба — программа, которая функционирует в фоновом режиме без взаимодействия с пользователем.

Сервисный файл/сервис — наиболее распространённый тип юнита:

systemd — система, управляющая всеми службами в системе.

systemctl — команда для взаимодействия с юнитами.

journalctl — команда для просмотра журналов и логов юнитов.

**********

Быстрый помощник - мини help

Чтобы отобразить все запущенные сервисные файлы (unit-файлы) в systemd, используйте одну из следующих команд:

systemctl list-units --type=service --state=running

📌 Покажет только работающие сервисы.

systemctl list-units --type=service

📌 Покажет все активные и неактивные сервисы.

systemctl list-unit-files --type=service

📌 Отобразит полный список всех доступных сервисов и их статус (enabled, disabled, static, masked и т. д.).

Если ты хочешь посмотреть информацию только про один сервис, например pop - это имя сервисного файла.:

systemctl status pop.service

или

systemctl list-units --type=service | grep pop

🔍 Выбери команду в зависимости от того, что именно нужно:

• Быстро увидеть запущенные сервисы → systemctl list-units --type=service --state=running

• Посмотреть все сервисы → systemctl list-units --type=service

• Проверить установленные unit-файлы → systemctl list-unit-files --type=service

• Найти конкретный сервис → systemctl status pop

Сервисный файл в системе Systemd представляет собой текстовый файл, который описывает, как управлять конкретной службой или программой в фоновом режиме. Эти файлы находятся в директории /etc/systemd/system/ и имеют расширение .service. Они используются для определения параметров запуска, остановки и управления сервисами в операционных системах, основанных на Linux.

Сервисный файл состоит из нескольких секций, каждая из которых выполняет определённые функции. Основные секции включают:

Эта секция содержит описание юнита и его зависимости. Она позволяет определить, когда и как должен быть запущен сервис.

Пример:

[Unit]
Description=My Sample Service
After=network.target

• Description — краткое описание сервиса.

• After — указывает на то, что этот сервис должен быть запущен после выполнения других юнитов, например, после настройки сети.

Секция [Service] определяет, как именно будет запускаться и управляться сам сервис. Здесь указываются команды для запуска, остановки, а также различные параметры работы сервиса.

Пример:

[Service]
ExecStart=/usr/bin/myapp --option
ExecStop=/usr/bin/myapp --stop
Restart=always

• ExecStart — команда для запуска сервиса.

• ExecStop — команда для остановки сервиса.

• Restart — параметр, указывающий, что сервис должен перезапускаться в случае сбоя.

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

Пример:

[Install]
WantedBy=multi-user.target

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

• [Unit] секция описывает, что сервис запускается после настройки сети.

• [Service] секция указывает команды для запуска и остановки сервиса, а также задаёт параметры перезапуска и указывает пользователя и группу, от имени которых будет запущен сервис.

• [Install] секция указывает, что сервис должен быть активирован в многопользовательском режиме.

Вот пример полного сервисного файла для проекта Babylon, работающего от имени пользователя root:

[Unit]
Description=Babylon Node Service
After=network.target

[Service]
User=root
Group=root
ExecStart=/usr/local/bin/babylon-node start --home /var/lib/babylon
ExecStop=/usr/local/bin/babylon-node stop --home /var/lib/babylon
Restart=on-failure
RestartSec=10
LimitNOFILE=4096
Environment=HOME=/var/lib/babylon

[Install]
WantedBy=multi-user.target

• [Unit]

  • Description: Описание сервиса — Babylon Node Service.

  • After: Указывает, что сервис должен запускаться после настройки сети.

• [Service]

  • User и Group: Указывают, что сервис будет запущен от имени пользователя и группы root.

  • ExecStart: Команда для запуска узла Babylon. Здесь используется путь /usr/local/bin/babylon-node и указана домашняя директория /var/lib/babylon.

  • ExecStop: Команда для корректной остановки узла Babylon.

  • Restart: Перезапуск сервиса в случае сбоя.

  • RestartSec: Задержка в секундах перед попыткой перезапуска.

  • LimitNOFILE: Устанавливает лимит открытых файлов.

  • Environment: Указывает домашнюю директорию для процесса.

• [Install]

Этот сервисный файл позволит автоматически запускать и управлять узлом Babylon при загрузке системы и в случае его остановки или сбоя.

После того как сервисный файл создан, следующим этапом является его настройка и управление. Это включает в себя регистрацию, активацию, запуск, перезапуск и мониторинг работы сервиса. Systemd предоставляет гибкие инструменты для выполнения этих задач, позволяя эффективно управлять фоновыми процессами в вашей системе.

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

sudo tee <<EOF >/dev/null /etc/systemd/system/babylon.service
[Unit]
Description=Babylon Node Service
After=network.target

[Service]
User=root
ExecStart=/usr/local/bin/babylon-node start --home /var/lib/babylon
ExecStop=/usr/local/bin/babylon-node stop --home /var/lib/babylon
Restart=on-failure
RestartSec=10
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target
EOF

В данном примере создаётся файл babylon.service с описанием настроек для запуска и управления узлом Babylon. После сохранения файла его нужно зарегистрировать в системе и добавить в автозагрузку.

После создания сервисного файла необходимо выполнить несколько шагов для его активации. Для этого используется команда systemctl.

sudo systemctl enable babylon.service

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

sudo systemctl daemon-reload

Эта команда перезагружает конфигурацию systemd, чтобы он увидел новый или изменённый сервисный файл.

sudo systemctl start babylon.service

Используйте команду start, чтобы немедленно запустить сервис. В случае изменений в сервисном файле лучше применять restart, так как он сначала остановит, а затем перезапустит сервис.

sudo systemctl restart babylon.service

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

Systemd предлагает ряд команд для управления юнитами и мониторинга их состояния.

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

  sudo systemctl start babylon.service
  

• Остановка сервиса:

  sudo systemctl stop babylon.service
  

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

  sudo systemctl restart babylon.service
  

• Проверка состояния сервиса:

  sudo systemctl is-active babylon.service
  

• Просмотр статуса и последних 10 строк лога:

  sudo systemctl status babylon.service
  

• Добавление в автозагрузку:

  sudo systemctl enable babylon.service
  

• Удаление из автозагрузки:

  sudo systemctl disable babylon.service
  

• Проверка, добавлен ли сервис в автозагрузку:

  sudo systemctl is-enabled babylon.service
  

• Просмотр содержимого сервисного файла:

  sudo systemctl cat babylon.service
  

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

sudo journalctl -f -n 100 -u babylon.service

Эта команда отображает последние 100 строк логов в режиме реального времени для сервиса Babylon.

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

Параметр Description предоставляет краткое текстовое описание сервиса. Это описание отображается в командах управления сервисами, таких как systemctl status, что помогает пользователю понять назначение сервиса.

Пример:

[Unit]
Description=My Custom Service

В данном примере описание указывает, что сервис — это "My Custom Service".

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

Пример:

[Unit]
Description=My Custom Service
After=network.target

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

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

Пример:

[Unit]
Description=My Custom Service
Requires=network.target
After=network.target

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

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

Пример:

[Unit]
Description=My Custom Service
Wants=redis.service
After=network.target

Здесь сервис пытается запустить redis.service, но его отсутствие не помешает запуску основного сервиса.

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

Пример:

[Unit]
Description=My Custom Service
Conflicts=old-service.service

В этом примере перед запуском сервиса My Custom Service будет остановлен old-service.service.

Параметр Before работает противоположно параметру After. Он указывает, что данный сервис должен быть запущен перед указанными юнитами.

Пример:

[Unit]
Description=My Custom Service
Before=nginx.service

Этот сервис будет запущен перед сервисом Nginx.

Параметр Documentation предоставляет ссылки на документацию, связанную с этим сервисом. Это могут быть URL или пути к файлам с документацией.

Пример:

[Unit]
Description=My Custom Service
Documentation=https://example.com/docs/my-service

Здесь указана ссылка на документацию, где можно узнать больше о работе сервиса.

Раздел [Unit] играет ключевую роль в определении зависимостей и порядка запуска сервиса. Правильная настройка параметров этого раздела обеспечивает стабильность и предсказуемость работы сервиса в системе. Понимание каждого параметра и его значения помогает создавать более надёжные и управляемые сервисные файлы.

Раздел [Service] в сервисном файле systemd определяет, как будет выполняться сам сервис. Этот раздел содержит ключевые параметры, которые описывают, как запускать, перезапускать и останавливать процесс, а также какие ограничения и настройки применять к нему. Правильная настройка раздела [Service] гарантирует стабильную и предсказуемую работу сервиса.

Параметр ExecStart задаёт команду, которая запускает основной процесс сервиса. Эта команда обязательно должна быть указана в каждом сервисном файле, поскольку именно она определяет, что будет выполнено при запуске сервиса.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run

В этом примере ExecStart запускает команду /usr/bin/my-service с параметром --run.

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

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
ExecStop=/usr/bin/my-service --stop

Здесь команда ExecStop останавливает сервис, выполняя команду с параметром --stop.

Параметр Restart задаёт условия, при которых systemd должен автоматически перезапустить сервис. Опции могут включать:

• no — сервис не будет перезапущен (по умолчанию).

• on-success — перезапускать, если процесс завершился с кодом успеха.

• on-failure — перезапускать при ошибках.

• always — перезапускать в любом случае.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
Restart=on-failure

В этом примере сервис будет перезапущен только в случае ошибки.

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

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
Restart=on-failure
RestartSec=5

Здесь сервис будет перезапускаться через 5 секунд после сбоя.

Параметры User и Group определяют пользователя и группу, от имени которых должен быть запущен сервис. Это важно для обеспечения безопасности и ограничения прав доступа.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
User=myuser
Group=mygroup

В этом примере сервис будет запущен от имени пользователя myuser и группы mygroup.

Параметр WorkingDirectory задаёт рабочую директорию, из которой будет выполняться команда запуска сервиса. Это полезно, если команда должна выполняться в определённом контексте.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
WorkingDirectory=/var/lib/my-service

Здесь команда будет выполняться в директории /var/lib/my-service.

Параметр Environment позволяет установить переменные окружения для процесса. Это полезно, если сервису нужны специальные настройки, такие как пути или ключи API.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
Environment="ENV_VAR=/path/to/file"

В данном примере переменная окружения ENV_VAR будет установлена перед запуском сервиса.

Параметр LimitNOFILE задаёт максимальное количество открытых файлов, разрешённых процессу. Это полезно для высоконагруженных сервисов, которым может потребоваться много дескрипторов файлов. Отдельным пунктом, будет рассмотрены остальные возможные параметры, читайте ниже “Установка мягких и жестких ограничений на различные ресурсы (limit, ulimit)”

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
LimitNOFILE=65535

В этом примере сервис может открыть до 65535 файлов одновременно.

Раздел [Service] является сердцем сервисного файла systemd, так как он определяет основные аспекты работы сервиса. Здесь настраиваются команды запуска и остановки, условия перезапуска, ограничения и многое другое. Правильная настройка этих параметров помогает обеспечить надёжную и предсказуемую работу сервиса в любой системе на базе Linux.

Раздел [Install] в сервисном файле systemd отвечает за настройку правил активации и установки сервиса в систему. В этом разделе определяются условия, при которых сервис будет включаться в процессе загрузки системы, а также зависимости от других юнитов.

Параметр WantedBy определяет цели (target), в которые будет включён сервис при активации. Этот параметр указывает на группы юнитов, к которым будет привязан сервис. Самый часто используемый вариант — multi-user.target, что соответствует стандартному многопользовательскому режиму работы без графического интерфейса.

Пример:

[Install]
WantedBy=multi-user.target

В данном примере сервис будет активирован при запуске системы в режиме multi-user, что означает, что он будет автоматически запускаться при переходе системы в этот режим.

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

Пример:

[Install]
RequiredBy=network.target

Этот пример означает, что если network.target не запущен, то и данный сервис не будет запущен.

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

Пример:

[Install]
WantedBy=multi-user.target
Also=my-other-service.service

Здесь при активации основного сервиса будет также активирован my-other-service.service.

Параметр Alias задаёт альтернативные имена для юнита. Это позволяет обращаться к сервису под разными именами.

Пример:

[Install]
Alias=my-service-alias.service

С этим параметром сервис может быть запущен, остановлен или перезапущен, используя имя my-service-alias.service.

Раздел [Install] служит для настройки условий активации и установки сервиса в систему. Параметры этого раздела определяют, в каких режимах работы системы сервис будет автоматически запускаться, а также позволяют связывать сервис с другими юнитами. Правильная настройка раздела [Install] обеспечивает автоматическую активацию и упрощает управление сервисом в операционной системе на базе Linux.

В сервисных файлах systemd параметр Limit используется для задания различных лимитов, которые определяют ограничения на ресурсы, доступные для процесса. Эти лимиты соответствуют стандартным ограничениям, устанавливаемым в системах Linux с помощью команды ulimit.

В systemd и других системных утилитах для обозначения размеров обычно применяются следующие единицы:

• K для килобайт

• M для мегабайт

• G для гигабайт

• T для терабайт

Вот основные критерии, которые можно использовать в сервисном файле с префиксом Limit:

1. **LimitCPU=**Ограничение времени процессора (в секундах), которое может использовать процесс. Устанавливается в виде времени процессора, доступного для процесса.

   Пример:

   LimitCPU=1min 30s
   или
   LimitCPU=50%
   

2. **CPUQuota=** Этот параметр задает лимит на использование процессорного времени в процентах от общего доступного времени на всех разрешенных ядрах. Проще говоря, вы можете ограничить службу так, чтобы она не использовала более определенного процента CPU.

   Пример:

   CPUQuota=50%
   

   CPUQuota=50% Ограничивает использование процессорного времени службой до 50% от общего доступного времени на всех разрешенных ядрах. Если у системы 4 ядра, то служба сможет использовать эквивалент полного времени двух ядер (50% от общего времени всех ядер).

3. **AllowedCPUs=** "Это параметр, который определяет, на каких ядрах процессора может выполняться служба. Этот параметр задается в виде списка номеров ядер или диапазона ядер, которые будут доступны для службы.

   Пример:

   AllowedCPUs=0-3 
   или 
   AllowedCPUs=0,2,4
   

   AllowedCPUs=0-3 - Ограничивает службу в использовании только первых четырех ядер (ядра 0, 1, 2, 3) процессора. Служба не будет задействовать другие ядра системы.

   AllowedCPUs=0,2,4 - Позволяет службе выполняться только на ядрах 0, 2 и 4, исключая использование других ядер процессора.

4. **LimitFSIZE=**Максимальный размер файлов, которые процесс может создать (в байтах).

   Пример:

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

Команда ulimit в Linux используется для управления лимитами ресурсов, которые может использовать оболочка и процессы, запущенные от этой оболочки. Эти лимиты помогают контролировать использование системных ресурсов и могут быть полезны для предотвращения их избыточного использования. Вот основные параметры, которые можно использовать с командой ulimit:

1. **-t (cpu time in seconds)**Ограничивает максимальное время работы процессора для процесса в секундах.

   Пример:

   ulimit -t 90
   

   Устанавливает лимит на 90 секунд процессорного времени.

2. **-f (file size in blocks)**Ограничивает максимальный размер файлов, которые процесс может создать. Размер указывается в блоках по 512 байт.

   Пример:

   ulimit -f 2048
   

   Устанавливает лимит на размер файла в 1 МБ (2048 блоков).

3. **-d (data segment size in kilobytes)**Ограничивает максимальный размер сегмента данных для процесса.

   Пример:

   ulimit -d 50000
   

   Устанавливает лимит на 50 МБ для сегмента данных.

4. **-s (stack size in kilobytes)**Ограничивает максимальный размер стека.

   Пример:

   ulimit -s 8192
   

   Устанавливает лимит на 8 МБ для стека.

5. **-c (core dump size in blocks)**Ограничивает максимальный размер файла дампа памяти (core dump). Размер указывается в блоках по 512 байт.

   Пример:

   ulimit -c 0
   

   Запрещает создание дампа памяти.

6. **-m (resident set size in kilobytes)**Ограничивает максимальный размер физической памяти, доступной для процесса.

   Пример:

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

Для задания лимитов в systemd для сервиса на сервере с характеристиками ( ssd\hdd\nvme - 500 Gb, ram (оперативная память) - 64 Gb и cpu (процессор) 16-ядерным процессором. Задача, ограничить ssd=100 Gb, ram=12Gb cpu=5 , можно использовать следующие параметры:

[Unit]
Description=Babylon Node Service
After=network.target

[Service]
User=root
ExecStart=/usr/local/bin/babylon-node start --home /var/lib/babylon
ExecStop=/usr/local/bin/babylon-node stop --home /var/lib/babylon
Restart=on-failure
RestartSec=10
LimitNOFILE=4096

# Ограничение на использование диска (используется для ограничения размера файлов, которые процесс может создать)
LimitFSIZE=100G

# Ограничение на использование процессорных ядер (используется для ограничения CPU времени)
LimitCPU=5

# Ограничение на использование оперативной памяти (RSS)
LimitRSS=12G


[Install]
WantedBy=multi-user.target

Второй пример

Ограничить использование памяти до 4 ГБ и дать доступ сервису к 2 ядрам процессора без жесткого закрепления (чтобы ресурсы использовались по мере необходимости).

sudo tee /etc/systemd/system/massad.service > /dev/null << EOF
[Unit]
Description=Massa Node
After=network-online.target
[Service]
User=$USER
WorkingDirectory=$USER/massa/massa-node
ExecStart=$HOME/massa/target/release/massa-node -p <PASSWORD>
Restart=on-failure
RestartSec=3
LimitNOFILE=4096

# Ограничения ресурсов
MemoryMax=4G             # Максимум 4 ГБ оперативной памяти
CPUQuota=200%            # Доступ к 2 ядрам процессора (200% = 2 ядра)

[Install]
WantedBy=multi-user.target
EOF

Cервисный файла systemd, в котором добавлены описания для каждого параметра Limit:

Спасибо за внимание к материалу! Надеюсь, информация оказалась полезной для вас! Поздравляю с новым достижением!

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

ПОЛЕЗНЫЕ ССЫЛКИ

В этом ОГЛАВЛЕНИИ собраны и структурированы все материалы.

About & Contact || Услуги || Donate || Отказ от ответственности | ©

Оглавление:

- Что такое сервисный файл?

- Быстрый помощник - мини help!

- Как выглядит сервисный файл?

- Взаимодействие с сервисным файлом.

- Параметры сервисного файла, Раздел [Unit].

- Параметры сервисного файла, Раздел [Service].

- Параметры сервисного файла, Раздел [Install].

- Установка мягких и жестких ограничений на различные ресурсы (limit, ulimit).

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

Сервисный файл (service) — это тип юнита (unit) в системе инициализации Systemd, которая используется в большинстве современных дистрибутивов Linux, таких как Ubuntu, CentOS и Debian. Однако, помимо сервисов, в Systemd существуют и другие типы юнитов, такие как target, mount, automount, slice, device, path, scope, snapshot и socket. Эти юниты играют различные роли в системе, обеспечивая её работоспособность и взаимодействие с внешними устройствами, управляя подключениями и состоянием системы.

Юниты — это ключевые компоненты Systemd, которые обеспечивают выполнение различных задач. Например, socket используется для управления сетевыми сокетами, а mount отвечает за монтирование файловых систем. Target помогает организовывать последовательность загрузки системы, а path следит за изменениями в определённых путях файловой системы. Device управляет обнаружением и подключением устройств, а automount автоматически монтирует файловые системы при доступе к ним.

Slice — это тип юнита, который делит ресурсы системы между различными группами процессов, что позволяет управлять их приоритетами и доступом к ресурсам. Scope представляет собой временный юнит, созданный для выполнения задач в определённом контексте. Snapshot используется для создания снимков состояния юнитов в определённый момент времени, что упрощает восстановление системы до предыдущего состояния.

Systemd управляет юнитами на протяжении всего времени работы компьютера — от загрузки до завершения. Процессы запускаются параллельно, что позволяет минимизировать время загрузки системы. Все юниты хранятся в каталоге /etc/systemd/system/, и их управлением занимается команда systemctl, с помощью которой можно запускать, останавливать и перезапускать юниты. Логи юнитов можно просматривать с помощью команды journalctl.

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

**********

РЕКОМЕНДАЦИЯ:

Мы настоятельно рекомендуем запускать все ноды в виде сервисных файлов и сами придерживаемся этого подхода в своих руководствах. Это решение обладает рядом преимуществ:

Фоновый режим работы: Сервисные файлы обеспечивают работу нод без необходимости вашего участия.

Автозапуск при старте системы: Ноды запускаются автоматически вместе с системой, что упрощает их использование.

Простое управление: Команды systemctl позволяют легко запускать, останавливать и перезапускать сервисы.

Краткое пояснение основных терминов:

Юнит/служба — программа, которая функционирует в фоновом режиме без взаимодействия с пользователем.

Сервисный файл/сервис — наиболее распространённый тип юнита:

systemd — система, управляющая всеми службами в системе.

systemctl — команда для взаимодействия с юнитами.

journalctl — команда для просмотра журналов и логов юнитов.

**********

Быстрый помощник - мини help

Чтобы отобразить все запущенные сервисные файлы (unit-файлы) в systemd, используйте одну из следующих команд:

systemctl list-units --type=service --state=running

📌 Покажет только работающие сервисы.

systemctl list-units --type=service

📌 Покажет все активные и неактивные сервисы.

systemctl list-unit-files --type=service

📌 Отобразит полный список всех доступных сервисов и их статус (enabled, disabled, static, masked и т. д.).

Если ты хочешь посмотреть информацию только про один сервис, например pop - это имя сервисного файла.:

systemctl status pop.service

или

systemctl list-units --type=service | grep pop

🔍 Выбери команду в зависимости от того, что именно нужно:

• Быстро увидеть запущенные сервисы → systemctl list-units --type=service --state=running

• Посмотреть все сервисы → systemctl list-units --type=service

• Проверить установленные unit-файлы → systemctl list-unit-files --type=service

• Найти конкретный сервис → systemctl status pop

Сервисный файл в системе Systemd представляет собой текстовый файл, который описывает, как управлять конкретной службой или программой в фоновом режиме. Эти файлы находятся в директории /etc/systemd/system/ и имеют расширение .service. Они используются для определения параметров запуска, остановки и управления сервисами в операционных системах, основанных на Linux.

Сервисный файл состоит из нескольких секций, каждая из которых выполняет определённые функции. Основные секции включают:

Эта секция содержит описание юнита и его зависимости. Она позволяет определить, когда и как должен быть запущен сервис.

Пример:

[Unit]
Description=My Sample Service
After=network.target

• Description — краткое описание сервиса.

• After — указывает на то, что этот сервис должен быть запущен после выполнения других юнитов, например, после настройки сети.

Секция [Service] определяет, как именно будет запускаться и управляться сам сервис. Здесь указываются команды для запуска, остановки, а также различные параметры работы сервиса.

Пример:

[Service]
ExecStart=/usr/bin/myapp --option
ExecStop=/usr/bin/myapp --stop
Restart=always

• ExecStart — команда для запуска сервиса.

• ExecStop — команда для остановки сервиса.

• Restart — параметр, указывающий, что сервис должен перезапускаться в случае сбоя.

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

Пример:

[Install]
WantedBy=multi-user.target

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

• [Unit] секция описывает, что сервис запускается после настройки сети.

• [Service] секция указывает команды для запуска и остановки сервиса, а также задаёт параметры перезапуска и указывает пользователя и группу, от имени которых будет запущен сервис.

• [Install] секция указывает, что сервис должен быть активирован в многопользовательском режиме.

Вот пример полного сервисного файла для проекта Babylon, работающего от имени пользователя root:

[Unit]
Description=Babylon Node Service
After=network.target

[Service]
User=root
Group=root
ExecStart=/usr/local/bin/babylon-node start --home /var/lib/babylon
ExecStop=/usr/local/bin/babylon-node stop --home /var/lib/babylon
Restart=on-failure
RestartSec=10
LimitNOFILE=4096
Environment=HOME=/var/lib/babylon

[Install]
WantedBy=multi-user.target

• [Unit]

  • Description: Описание сервиса — Babylon Node Service.

  • After: Указывает, что сервис должен запускаться после настройки сети.

• [Service]

  • User и Group: Указывают, что сервис будет запущен от имени пользователя и группы root.

  • ExecStart: Команда для запуска узла Babylon. Здесь используется путь /usr/local/bin/babylon-node и указана домашняя директория /var/lib/babylon.

  • ExecStop: Команда для корректной остановки узла Babylon.

  • Restart: Перезапуск сервиса в случае сбоя.

  • RestartSec: Задержка в секундах перед попыткой перезапуска.

  • LimitNOFILE: Устанавливает лимит открытых файлов.

  • Environment: Указывает домашнюю директорию для процесса.

• [Install]

Этот сервисный файл позволит автоматически запускать и управлять узлом Babylon при загрузке системы и в случае его остановки или сбоя.

После того как сервисный файл создан, следующим этапом является его настройка и управление. Это включает в себя регистрацию, активацию, запуск, перезапуск и мониторинг работы сервиса. Systemd предоставляет гибкие инструменты для выполнения этих задач, позволяя эффективно управлять фоновыми процессами в вашей системе.

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

sudo tee <<EOF >/dev/null /etc/systemd/system/babylon.service
[Unit]
Description=Babylon Node Service
After=network.target

[Service]
User=root
ExecStart=/usr/local/bin/babylon-node start --home /var/lib/babylon
ExecStop=/usr/local/bin/babylon-node stop --home /var/lib/babylon
Restart=on-failure
RestartSec=10
LimitNOFILE=4096

[Install]
WantedBy=multi-user.target
EOF

В данном примере создаётся файл babylon.service с описанием настроек для запуска и управления узлом Babylon. После сохранения файла его нужно зарегистрировать в системе и добавить в автозагрузку.

После создания сервисного файла необходимо выполнить несколько шагов для его активации. Для этого используется команда systemctl.

sudo systemctl enable babylon.service

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

sudo systemctl daemon-reload

Эта команда перезагружает конфигурацию systemd, чтобы он увидел новый или изменённый сервисный файл.

sudo systemctl start babylon.service

Используйте команду start, чтобы немедленно запустить сервис. В случае изменений в сервисном файле лучше применять restart, так как он сначала остановит, а затем перезапустит сервис.

sudo systemctl restart babylon.service

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

Systemd предлагает ряд команд для управления юнитами и мониторинга их состояния.

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

  sudo systemctl start babylon.service
  

• Остановка сервиса:

  sudo systemctl stop babylon.service
  

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

  sudo systemctl restart babylon.service
  

• Проверка состояния сервиса:

  sudo systemctl is-active babylon.service
  

• Просмотр статуса и последних 10 строк лога:

  sudo systemctl status babylon.service
  

• Добавление в автозагрузку:

  sudo systemctl enable babylon.service
  

• Удаление из автозагрузки:

  sudo systemctl disable babylon.service
  

• Проверка, добавлен ли сервис в автозагрузку:

  sudo systemctl is-enabled babylon.service
  

• Просмотр содержимого сервисного файла:

  sudo systemctl cat babylon.service
  

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

sudo journalctl -f -n 100 -u babylon.service

Эта команда отображает последние 100 строк логов в режиме реального времени для сервиса Babylon.

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

Параметр Description предоставляет краткое текстовое описание сервиса. Это описание отображается в командах управления сервисами, таких как systemctl status, что помогает пользователю понять назначение сервиса.

Пример:

[Unit]
Description=My Custom Service

В данном примере описание указывает, что сервис — это "My Custom Service".

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

Пример:

[Unit]
Description=My Custom Service
After=network.target

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

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

Пример:

[Unit]
Description=My Custom Service
Requires=network.target
After=network.target

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

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

Пример:

[Unit]
Description=My Custom Service
Wants=redis.service
After=network.target

Здесь сервис пытается запустить redis.service, но его отсутствие не помешает запуску основного сервиса.

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

Пример:

[Unit]
Description=My Custom Service
Conflicts=old-service.service

В этом примере перед запуском сервиса My Custom Service будет остановлен old-service.service.

Параметр Before работает противоположно параметру After. Он указывает, что данный сервис должен быть запущен перед указанными юнитами.

Пример:

[Unit]
Description=My Custom Service
Before=nginx.service

Этот сервис будет запущен перед сервисом Nginx.

Параметр Documentation предоставляет ссылки на документацию, связанную с этим сервисом. Это могут быть URL или пути к файлам с документацией.

Пример:

[Unit]
Description=My Custom Service
Documentation=https://example.com/docs/my-service

Здесь указана ссылка на документацию, где можно узнать больше о работе сервиса.

Раздел [Unit] играет ключевую роль в определении зависимостей и порядка запуска сервиса. Правильная настройка параметров этого раздела обеспечивает стабильность и предсказуемость работы сервиса в системе. Понимание каждого параметра и его значения помогает создавать более надёжные и управляемые сервисные файлы.

Раздел [Service] в сервисном файле systemd определяет, как будет выполняться сам сервис. Этот раздел содержит ключевые параметры, которые описывают, как запускать, перезапускать и останавливать процесс, а также какие ограничения и настройки применять к нему. Правильная настройка раздела [Service] гарантирует стабильную и предсказуемую работу сервиса.

Параметр ExecStart задаёт команду, которая запускает основной процесс сервиса. Эта команда обязательно должна быть указана в каждом сервисном файле, поскольку именно она определяет, что будет выполнено при запуске сервиса.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run

В этом примере ExecStart запускает команду /usr/bin/my-service с параметром --run.

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

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
ExecStop=/usr/bin/my-service --stop

Здесь команда ExecStop останавливает сервис, выполняя команду с параметром --stop.

Параметр Restart задаёт условия, при которых systemd должен автоматически перезапустить сервис. Опции могут включать:

• no — сервис не будет перезапущен (по умолчанию).

• on-success — перезапускать, если процесс завершился с кодом успеха.

• on-failure — перезапускать при ошибках.

• always — перезапускать в любом случае.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
Restart=on-failure

В этом примере сервис будет перезапущен только в случае ошибки.

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

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
Restart=on-failure
RestartSec=5

Здесь сервис будет перезапускаться через 5 секунд после сбоя.

Параметры User и Group определяют пользователя и группу, от имени которых должен быть запущен сервис. Это важно для обеспечения безопасности и ограничения прав доступа.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
User=myuser
Group=mygroup

В этом примере сервис будет запущен от имени пользователя myuser и группы mygroup.

Параметр WorkingDirectory задаёт рабочую директорию, из которой будет выполняться команда запуска сервиса. Это полезно, если команда должна выполняться в определённом контексте.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
WorkingDirectory=/var/lib/my-service

Здесь команда будет выполняться в директории /var/lib/my-service.

Параметр Environment позволяет установить переменные окружения для процесса. Это полезно, если сервису нужны специальные настройки, такие как пути или ключи API.

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
Environment="ENV_VAR=/path/to/file"

В данном примере переменная окружения ENV_VAR будет установлена перед запуском сервиса.

Параметр LimitNOFILE задаёт максимальное количество открытых файлов, разрешённых процессу. Это полезно для высоконагруженных сервисов, которым может потребоваться много дескрипторов файлов. Отдельным пунктом, будет рассмотрены остальные возможные параметры, читайте ниже “Установка мягких и жестких ограничений на различные ресурсы (limit, ulimit)”

Пример:

[Service]
ExecStart=/usr/bin/my-service --run
LimitNOFILE=65535

В этом примере сервис может открыть до 65535 файлов одновременно.

Раздел [Service] является сердцем сервисного файла systemd, так как он определяет основные аспекты работы сервиса. Здесь настраиваются команды запуска и остановки, условия перезапуска, ограничения и многое другое. Правильная настройка этих параметров помогает обеспечить надёжную и предсказуемую работу сервиса в любой системе на базе Linux.

Раздел [Install] в сервисном файле systemd отвечает за настройку правил активации и установки сервиса в систему. В этом разделе определяются условия, при которых сервис будет включаться в процессе загрузки системы, а также зависимости от других юнитов.

Параметр WantedBy определяет цели (target), в которые будет включён сервис при активации. Этот параметр указывает на группы юнитов, к которым будет привязан сервис. Самый часто используемый вариант — multi-user.target, что соответствует стандартному многопользовательскому режиму работы без графического интерфейса.

Пример:

[Install]
WantedBy=multi-user.target

В данном примере сервис будет активирован при запуске системы в режиме multi-user, что означает, что он будет автоматически запускаться при переходе системы в этот режим.

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

Пример:

[Install]
RequiredBy=network.target

Этот пример означает, что если network.target не запущен, то и данный сервис не будет запущен.

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

Пример:

[Install]
WantedBy=multi-user.target
Also=my-other-service.service

Здесь при активации основного сервиса будет также активирован my-other-service.service.

Параметр Alias задаёт альтернативные имена для юнита. Это позволяет обращаться к сервису под разными именами.

Пример:

[Install]
Alias=my-service-alias.service

С этим параметром сервис может быть запущен, остановлен или перезапущен, используя имя my-service-alias.service.

Раздел [Install] служит для настройки условий активации и установки сервиса в систему. Параметры этого раздела определяют, в каких режимах работы системы сервис будет автоматически запускаться, а также позволяют связывать сервис с другими юнитами. Правильная настройка раздела [Install] обеспечивает автоматическую активацию и упрощает управление сервисом в операционной системе на базе Linux.

В сервисных файлах systemd параметр Limit используется для задания различных лимитов, которые определяют ограничения на ресурсы, доступные для процесса. Эти лимиты соответствуют стандартным ограничениям, устанавливаемым в системах Linux с помощью команды ulimit.

В systemd и других системных утилитах для обозначения размеров обычно применяются следующие единицы:

• K для килобайт

• M для мегабайт

• G для гигабайт

• T для терабайт

Вот основные критерии, которые можно использовать в сервисном файле с префиксом Limit:

1. **LimitCPU=**Ограничение времени процессора (в секундах), которое может использовать процесс. Устанавливается в виде времени процессора, доступного для процесса.

   Пример:

   LimitCPU=1min 30s
   или
   LimitCPU=50%
   

2. **CPUQuota=** Этот параметр задает лимит на использование процессорного времени в процентах от общего доступного времени на всех разрешенных ядрах. Проще говоря, вы можете ограничить службу так, чтобы она не использовала более определенного процента CPU.

   Пример:

   CPUQuota=50%
   

   CPUQuota=50% Ограничивает использование процессорного времени службой до 50% от общего доступного времени на всех разрешенных ядрах. Если у системы 4 ядра, то служба сможет использовать эквивалент полного времени двух ядер (50% от общего времени всех ядер).

3. **AllowedCPUs=** "Это параметр, который определяет, на каких ядрах процессора может выполняться служба. Этот параметр задается в виде списка номеров ядер или диапазона ядер, которые будут доступны для службы.

   Пример:

   AllowedCPUs=0-3 
   или 
   AllowedCPUs=0,2,4
   

   AllowedCPUs=0-3 - Ограничивает службу в использовании только первых четырех ядер (ядра 0, 1, 2, 3) процессора. Служба не будет задействовать другие ядра системы.

   AllowedCPUs=0,2,4 - Позволяет службе выполняться только на ядрах 0, 2 и 4, исключая использование других ядер процессора.

4. **LimitFSIZE=**Максимальный размер файлов, которые процесс может создать (в байтах).

   Пример:

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

Команда ulimit в Linux используется для управления лимитами ресурсов, которые может использовать оболочка и процессы, запущенные от этой оболочки. Эти лимиты помогают контролировать использование системных ресурсов и могут быть полезны для предотвращения их избыточного использования. Вот основные параметры, которые можно использовать с командой ulimit:

1. **-t (cpu time in seconds)**Ограничивает максимальное время работы процессора для процесса в секундах.

   Пример:

   ulimit -t 90
   

   Устанавливает лимит на 90 секунд процессорного времени.

2. **-f (file size in blocks)**Ограничивает максимальный размер файлов, которые процесс может создать. Размер указывается в блоках по 512 байт.

   Пример:

   ulimit -f 2048
   

   Устанавливает лимит на размер файла в 1 МБ (2048 блоков).

3. **-d (data segment size in kilobytes)**Ограничивает максимальный размер сегмента данных для процесса.

   Пример:

   ulimit -d 50000
   

   Устанавливает лимит на 50 МБ для сегмента данных.

4. **-s (stack size in kilobytes)**Ограничивает максимальный размер стека.

   Пример:

   ulimit -s 8192
   

   Устанавливает лимит на 8 МБ для стека.

5. **-c (core dump size in blocks)**Ограничивает максимальный размер файла дампа памяти (core dump). Размер указывается в блоках по 512 байт.

   Пример:

   ulimit -c 0
   

   Запрещает создание дампа памяти.

6. **-m (resident set size in kilobytes)**Ограничивает максимальный размер физической памяти, доступной для процесса.

   Пример:

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

Для задания лимитов в systemd для сервиса на сервере с характеристиками ( ssd\hdd\nvme - 500 Gb, ram (оперативная память) - 64 Gb и cpu (процессор) 16-ядерным процессором. Задача, ограничить ssd=100 Gb, ram=12Gb cpu=5 , можно использовать следующие параметры:

[Unit]
Description=Babylon Node Service
After=network.target

[Service]
User=root
ExecStart=/usr/local/bin/babylon-node start --home /var/lib/babylon
ExecStop=/usr/local/bin/babylon-node stop --home /var/lib/babylon
Restart=on-failure
RestartSec=10
LimitNOFILE=4096

# Ограничение на использование диска (используется для ограничения размера файлов, которые процесс может создать)
LimitFSIZE=100G

# Ограничение на использование процессорных ядер (используется для ограничения CPU времени)
LimitCPU=5

# Ограничение на использование оперативной памяти (RSS)
LimitRSS=12G


[Install]
WantedBy=multi-user.target

Второй пример

Ограничить использование памяти до 4 ГБ и дать доступ сервису к 2 ядрам процессора без жесткого закрепления (чтобы ресурсы использовались по мере необходимости).

sudo tee /etc/systemd/system/massad.service > /dev/null << EOF
[Unit]
Description=Massa Node
After=network-online.target
[Service]
User=$USER
WorkingDirectory=$USER/massa/massa-node
ExecStart=$HOME/massa/target/release/massa-node -p <PASSWORD>
Restart=on-failure
RestartSec=3
LimitNOFILE=4096

# Ограничения ресурсов
MemoryMax=4G             # Максимум 4 ГБ оперативной памяти
CPUQuota=200%            # Доступ к 2 ядрам процессора (200% = 2 ядра)

[Install]
WantedBy=multi-user.target
EOF

Cервисный файла systemd, в котором добавлены описания для каждого параметра Limit:

Спасибо за внимание к материалу! Надеюсь, информация оказалась полезной для вас! Поздравляю с новым достижением!

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

ПОЛЕЗНЫЕ ССЫЛКИ

В этом ОГЛАВЛЕНИИ собраны и структурированы все материалы.

About & Contact || Услуги || Donate || Отказ от ответственности | ©