Оглавление:
- Что такое сервисный файл?
- Быстрый помощник - мини 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]Эта секция содержит описание юнита и его зависимости. Она позволяет определить, когда и как должен быть запущен сервис.
Пример:
[Unit]
Description=My Sample Service
After=network.target
Description — краткое описание сервиса.
After — указывает на то, что этот сервис должен быть запущен после выполнения других юнитов, например, после настройки сети.
[Service]Секция [Service] определяет, как именно будет запускаться и управляться сам сервис. Здесь указываются команды для запуска, остановки, а также различные параметры работы сервиса.
Пример:
[Service]
ExecStart=/usr/bin/myapp --option
ExecStop=/usr/bin/myapp --stop
Restart=always
ExecStart — команда для запуска сервиса.
ExecStop — команда для остановки сервиса.
Restart — параметр, указывающий, что сервис должен перезапускаться в случае сбоя.
[Install]Эта секция описывает, как и когда должен быть активирован или деактивирован сервис, включая настройку автозапуска.
Пример:
[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]
WantedBy: Указывает, что сервис должен быть запущен в многопользовательском режиме.Этот сервисный файл позволит автоматически запускать и управлять узлом 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 отвечает за описание метаинформации и зависимостей конкретного сервиса. Этот раздел определяет, как сервис взаимодействует с другими юнитами и в каких условиях должен быть запущен. Важно правильно настроить параметры в этом разделе, чтобы обеспечить корректную работу сервиса и его интеграцию с системой.
[Unit]DescriptionПараметр Description предоставляет краткое текстовое описание сервиса. Это описание отображается в командах управления сервисами, таких как systemctl status, что помогает пользователю понять назначение сервиса.
Пример:
[Unit]
Description=My Custom Service
В данном примере описание указывает, что сервис — это "My Custom Service".
AfterПараметр After определяет, после каких юнитов должен быть запущен данный сервис. Важно отметить, что After устанавливает порядок запуска, но не создает зависимости. Если сервис должен зависеть от другого юнита, нужно использовать параметр Requires.
Пример:
[Unit]
Description=My Custom Service
After=network.target
Здесь сервис будет запущен после настройки сети, что полезно для сервисов, которым требуется подключение к интернету.
RequiresПараметр Requires создает жесткую зависимость от других юнитов. Если указанные юниты не могут быть запущены, то данный сервис также не будет запущен.
Пример:
[Unit]
Description=My Custom Service
Requires=network.target
After=network.target
Этот пример указывает, что сервис не будет запущен, если сеть не настроена.
WantsПараметр Wants похож на Requires, но зависимость не является критической. Если зависимый юнит не может быть запущен, это не помешает запуску основного сервиса.
Пример:
[Unit]
Description=My Custom Service
Wants=redis.service
After=network.target
Здесь сервис пытается запустить redis.service, но его отсутствие не помешает запуску основного сервиса.
ConflictsПараметр Conflicts указывает, что данный сервис не может быть запущен одновременно с указанными юнитами. Если конфликтующий юнит запущен, он будет остановлен перед запуском этого сервиса.
Пример:
[Unit]
Description=My Custom Service
Conflicts=old-service.service
В этом примере перед запуском сервиса My Custom Service будет остановлен old-service.service.
BeforeПараметр Before работает противоположно параметру After. Он указывает, что данный сервис должен быть запущен перед указанными юнитами.
Пример:
[Unit]
Description=My Custom Service
Before=nginx.service
Этот сервис будет запущен перед сервисом Nginx.
DocumentationПараметр Documentation предоставляет ссылки на документацию, связанную с этим сервисом. Это могут быть URL или пути к файлам с документацией.
Пример:
[Unit]
Description=My Custom Service
Documentation=https://example.com/docs/my-service
Здесь указана ссылка на документацию, где можно узнать больше о работе сервиса.
Раздел [Unit] играет ключевую роль в определении зависимостей и порядка запуска сервиса. Правильная настройка параметров этого раздела обеспечивает стабильность и предсказуемость работы сервиса в системе. Понимание каждого параметра и его значения помогает создавать более надёжные и управляемые сервисные файлы.
Раздел [Service] в сервисном файле systemd определяет, как будет выполняться сам сервис. Этот раздел содержит ключевые параметры, которые описывают, как запускать, перезапускать и останавливать процесс, а также какие ограничения и настройки применять к нему. Правильная настройка раздела [Service] гарантирует стабильную и предсказуемую работу сервиса.
[Service]ExecStartПараметр ExecStart задаёт команду, которая запускает основной процесс сервиса. Эта команда обязательно должна быть указана в каждом сервисном файле, поскольку именно она определяет, что будет выполнено при запуске сервиса.
Пример:
[Service]
ExecStart=/usr/bin/my-service --run
В этом примере ExecStart запускает команду /usr/bin/my-service с параметром --run.
ExecStopПараметр ExecStop определяет команду, которая должна быть выполнена для корректной остановки сервиса. Этот параметр не обязателен, но полезен для случаев, когда нужно выполнить определённые действия при остановке сервиса.
Пример:
[Service]
ExecStart=/usr/bin/my-service --run
ExecStop=/usr/bin/my-service --stop
Здесь команда ExecStop останавливает сервис, выполняя команду с параметром --stop.
RestartПараметр Restart задаёт условия, при которых systemd должен автоматически перезапустить сервис. Опции могут включать:
no — сервис не будет перезапущен (по умолчанию).
on-success — перезапускать, если процесс завершился с кодом успеха.
on-failure — перезапускать при ошибках.
always — перезапускать в любом случае.
Пример:
[Service]
ExecStart=/usr/bin/my-service --run
Restart=on-failure
В этом примере сервис будет перезапущен только в случае ошибки.
RestartSecПараметр RestartSec определяет задержку в секундах перед перезапуском сервиса после сбоя. Это может быть полезно для предотвращения слишком частых перезапусков.
Пример:
[Service]
ExecStart=/usr/bin/my-service --run
Restart=on-failure
RestartSec=5
Здесь сервис будет перезапускаться через 5 секунд после сбоя.
User и GroupПараметры User и Group определяют пользователя и группу, от имени которых должен быть запущен сервис. Это важно для обеспечения безопасности и ограничения прав доступа.
Пример:
[Service]
ExecStart=/usr/bin/my-service --run
User=myuser
Group=mygroup
В этом примере сервис будет запущен от имени пользователя myuser и группы mygroup.
WorkingDirectoryПараметр WorkingDirectory задаёт рабочую директорию, из которой будет выполняться команда запуска сервиса. Это полезно, если команда должна выполняться в определённом контексте.
Пример:
[Service]
ExecStart=/usr/bin/my-service --run
WorkingDirectory=/var/lib/my-service
Здесь команда будет выполняться в директории /var/lib/my-service.
EnvironmentПараметр Environment позволяет установить переменные окружения для процесса. Это полезно, если сервису нужны специальные настройки, такие как пути или ключи API.
Пример:
[Service]
ExecStart=/usr/bin/my-service --run
Environment="ENV_VAR=/path/to/file"
В данном примере переменная окружения ENV_VAR будет установлена перед запуском сервиса.
LimitNOFILEПараметр LimitNOFILE задаёт максимальное количество открытых файлов, разрешённых процессу. Это полезно для высоконагруженных сервисов, которым может потребоваться много дескрипторов файлов. Отдельным пунктом, будет рассмотрены остальные возможные параметры, читайте ниже “Установка мягких и жестких ограничений на различные ресурсы (limit, ulimit)”
Пример:
[Service]
ExecStart=/usr/bin/my-service --run
LimitNOFILE=65535
В этом примере сервис может открыть до 65535 файлов одновременно.
Раздел [Service] является сердцем сервисного файла systemd, так как он определяет основные аспекты работы сервиса. Здесь настраиваются команды запуска и остановки, условия перезапуска, ограничения и многое другое. Правильная настройка этих параметров помогает обеспечить надёжную и предсказуемую работу сервиса в любой системе на базе Linux.
Раздел [Install] в сервисном файле systemd отвечает за настройку правил активации и установки сервиса в систему. В этом разделе определяются условия, при которых сервис будет включаться в процессе загрузки системы, а также зависимости от других юнитов.
[Install]WantedByПараметр WantedBy определяет цели (target), в которые будет включён сервис при активации. Этот параметр указывает на группы юнитов, к которым будет привязан сервис. Самый часто используемый вариант — multi-user.target, что соответствует стандартному многопользовательскому режиму работы без графического интерфейса.
Пример:
[Install]
WantedBy=multi-user.target
В данном примере сервис будет активирован при запуске системы в режиме multi-user, что означает, что он будет автоматически запускаться при переходе системы в этот режим.
RequiredByПараметр RequiredBy работает аналогично WantedBy, но с более жесткой зависимостью. Если юнит, указанный в RequiredBy, не будет активирован, зависимый от него юнит также не будет запущен.
Пример:
[Install]
RequiredBy=network.target
Этот пример означает, что если network.target не запущен, то и данный сервис не будет запущен.
AlsoПараметр Also указывает на дополнительные юниты, которые должны быть активированы или деактивированы вместе с данным юнитом. Это полезно для сервисов, которые имеют несколько связанных компонентов.
Пример:
[Install]
WantedBy=multi-user.target
Also=my-other-service.service
Здесь при активации основного сервиса будет также активирован my-other-service.service.
AliasПараметр Alias задаёт альтернативные имена для юнита. Это позволяет обращаться к сервису под разными именами.
Пример:
[Install]
Alias=my-service-alias.service
С этим параметром сервис может быть запущен, остановлен или перезапущен, используя имя my-service-alias.service.
Раздел [Install] служит для настройки условий активации и установки сервиса в систему. Параметры этого раздела определяют, в каких режимах работы системы сервис будет автоматически запускаться, а также позволяют связывать сервис с другими юнитами. Правильная настройка раздела [Install] обеспечивает автоматическую активацию и упрощает управление сервисом в операционной системе на базе Linux.
В сервисных файлах systemd параметр Limit используется для задания различных лимитов, которые определяют ограничения на ресурсы, доступные для процесса. Эти лимиты соответствуют стандартным ограничениям, устанавливаемым в системах Linux с помощью команды ulimit.
В systemd и других системных утилитах для обозначения размеров обычно применяются следующие единицы:
K для килобайт
M для мегабайт
G для гигабайт
T для терабайт
Вот основные критерии, которые можно использовать в сервисном файле с префиксом Limit:
**LimitCPU=**Ограничение времени процессора (в секундах), которое может использовать процесс. Устанавливается в виде времени процессора, доступного для процесса.
Пример:
LimitCPU=1min 30s
или
LimitCPU=50%
**CPUQuota=** Этот параметр задает лимит на использование процессорного времени в процентах от общего доступного времени на всех разрешенных ядрах. Проще говоря, вы можете ограничить службу так, чтобы она не использовала более определенного процента CPU.
Пример:
CPUQuota=50%
CPUQuota=50% Ограничивает использование процессорного времени службой до 50% от общего доступного времени на всех разрешенных ядрах. Если у системы 4 ядра, то служба сможет использовать эквивалент полного времени двух ядер (50% от общего времени всех ядер).
**AllowedCPUs=** "Это параметр, который определяет, на каких ядрах процессора может выполняться служба. Этот параметр задается в виде списка номеров ядер или диапазона ядер, которые будут доступны для службы.
Пример:
AllowedCPUs=0-3
или
AllowedCPUs=0,2,4
AllowedCPUs=0-3 - Ограничивает службу в использовании только первых четырех ядер (ядра 0, 1, 2, 3) процессора. Служба не будет задействовать другие ядра системы.
AllowedCPUs=0,2,4 - Позволяет службе выполняться только на ядрах 0, 2 и 4, исключая использование других ядер процессора.
**LimitFSIZE=**Максимальный размер файлов, которые процесс может создать (в байтах).
Пример:
LimitFSIZE=10M
**LimitDATA=**Максимальный размер сегмента данных (в байтах), который процесс может использовать.
Пример:
LimitDATA=50M
**LimitSTACK=**Максимальный размер стека (в байтах) для процесса.
Пример:
LimitSTACK=8M
**LimitCORE=**Максимальный размер дампа памяти (core dump), который может быть создан процессом (в байтах).
Пример:
LimitCORE=0
**LimitRSS=**Ограничение на размер физической памяти (Resident Set Size), используемой процессом (в байтах).
Пример:
LimitRSS=100M
**LimitNOFILE=**Максимальное количество открытых файловых дескрипторов, разрешенных для процесса.
Пример:
LimitNOFILE=65536
**LimitAS=**Ограничение на максимальный размер адресного пространства, доступного для процесса (в байтах).
Пример:
LimitAS=500M
**LimitNPROC=**Ограничение на максимальное количество дочерних процессов, которые может запустить данный процесс.
Пример:
LimitNPROC=1024
**LimitMEMLOCK=**Максимальный объем памяти, который процесс может зафиксировать в оперативной памяти (в байтах).
Пример:
LimitMEMLOCK=64M
**LimitLOCKS=**Ограничение на количество файловых блокировок, которые может удерживать процесс.
Пример:
LimitLOCKS=512
**LimitSIGPENDING=**Максимальное количество отложенных сигналов, разрешенных для пользователя, запускающего процесс.
Пример:
LimitSIGPENDING=1024
**LimitMSGQUEUE=**Ограничение на размер очередей сообщений, доступных процессу (в байтах).
Пример:
LimitMSGQUEUE=8192
**LimitNICE=**Устанавливает лимит для значения приоритета (niceness) процесса.
Пример:
LimitNICE=10
**LimitRTPRIO=**Устанавливает максимальный приоритет для процессов реального времени (real-time priority).
Пример:
LimitRTPRIO=20
**LimitRTTIME=**Максимальное время выполнения в реальном времени, разрешенное для процесса (в микросекундах).
Пример:
LimitRTTIME=1s
Эти параметры позволяют детально управлять ресурсами, доступными для процессов, и предотвращать их чрезмерное использование, что особенно важно для критичных системных сервисов.
Команда ulimit в Linux используется для управления лимитами ресурсов, которые может использовать оболочка и процессы, запущенные от этой оболочки. Эти лимиты помогают контролировать использование системных ресурсов и могут быть полезны для предотвращения их избыточного использования. Вот основные параметры, которые можно использовать с командой ulimit:
**-t (cpu time in seconds)**Ограничивает максимальное время работы процессора для процесса в секундах.
Пример:
ulimit -t 90
Устанавливает лимит на 90 секунд процессорного времени.
**-f (file size in blocks)**Ограничивает максимальный размер файлов, которые процесс может создать. Размер указывается в блоках по 512 байт.
Пример:
ulimit -f 2048
Устанавливает лимит на размер файла в 1 МБ (2048 блоков).
**-d (data segment size in kilobytes)**Ограничивает максимальный размер сегмента данных для процесса.
Пример:
ulimit -d 50000
Устанавливает лимит на 50 МБ для сегмента данных.
**-s (stack size in kilobytes)**Ограничивает максимальный размер стека.
Пример:
ulimit -s 8192
Устанавливает лимит на 8 МБ для стека.
**-c (core dump size in blocks)**Ограничивает максимальный размер файла дампа памяти (core dump). Размер указывается в блоках по 512 байт.
Пример:
ulimit -c 0
Запрещает создание дампа памяти.
**-m (resident set size in kilobytes)**Ограничивает максимальный размер физической памяти, доступной для процесса.
Пример:
ulimit -m 100000
Устанавливает лимит на 100 МБ физической памяти.
**-n (number of open file descriptors)**Ограничивает количество файловых дескрипторов, которые процесс может открыть.
Пример:
ulimit -n 1024
Устанавливает лимит на 1024 открытых файла.
**-u (number of user processes)**Ограничивает количество процессов, которые пользователь может запустить одновременно.
Пример:
ulimit -u 200
Ограничивает количество процессов до 200.
**-v (virtual memory in kilobytes)**Ограничивает объем виртуальной памяти, доступной для процесса.
Пример:
ulimit -v 200000
Устанавливает лимит на 200 МБ виртуальной памяти.
**-l (locked-in-memory size in kilobytes)**Ограничивает объем памяти, который процесс может зафиксировать в оперативной памяти.
Пример:
ulimit -l 65536
Ограничивает фиксацию памяти до 64 МБ.
**-x (file locks)**Ограничивает количество файловых блокировок, которые может удерживать процесс.
Пример:
ulimit -x 128
Устанавливает лимит на 128 файловых блокировок.
**-q (bytes in POSIX message queues)**Ограничивает размер очереди сообщений POSIX, которую может использовать процесс.
Пример:
ulimit -q 8192
Устанавливает лимит на 8192 байта в очереди сообщений.
**-e (nice value)**Устанавливает значение приоритета (niceness) процесса.
Пример:
ulimit -e 10
Устанавливает приоритет с nice=10.
**-r (real-time priority)**Устанавливает максимальный приоритет процессов реального времени.
Пример:
ulimit -r 20
Ограничивает реальный приоритет до 20.
**-i (pending signals)**Ограничивает количество отложенных сигналов, доступных процессу.
Пример:
ulimit -i 4096
Ограничивает количество отложенных сигналов до 4096.
Эти параметры 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:
[Unit]
Description=Example Service with Resource Limits
[Service]
ExecStart=/usr/bin/example
# Ограничение размера файлов, которые процесс может создать. Устанавливается в 100 ГБ.
# Это ограничение помогает предотвратить чрезмерное использование дискового пространства процессом.
LimitFSIZE=100G
# Ограничение использования процессорных ядер. В данном случае установлено на 5 ядер.
# Это ограничение определяет, сколько ядер процесс может использовать для выполнения своих задач.
LimitCPU=5
# Ограничение на использование оперативной памяти. Установлено на 12 ГБ.
# Этот параметр контролирует максимальный объем физической памяти (RSS), который процесс может использовать.
LimitRSS=12G
# Ограничение на максимальный размер сегмента данных, который процесс может использовать. Установлено на 12 ГБ.
# Это ограничение предотвращает чрезмерное использование адресного пространства для данных.
LimitDATA=12G
# Ограничение на максимальный размер стека. Установлено на 8 МБ.
# Это ограничение задает размер памяти, выделенной для стека процесса.
LimitSTACK=8M
# Ограничение на максимальный размер дампа памяти (core dump). Установлено на 0, что означает отсутствие дампов.
# Это ограничение предотвращает создание дампов памяти, которые могут занимать много дискового пространства.
LimitCORE=0
# Ограничение на максимальный объем памяти, который процесс может зафиксировать в оперативной памяти. Установлено на 64 МБ.
# Этот параметр ограничивает объем памяти, которую процесс может заблокировать и удерживать в оперативной памяти.
LimitMEMLOCK=64M
# Ограничение на максимальное количество открытых файловых дескрипторов. Установлено на 65536.
# Это ограничение определяет, сколько файлов процесс может открыть одновременно.
LimitNOFILE=65536
# Ограничение на максимальный размер адресного пространства, доступного для процесса. Установлено на 16 ГБ.
# Это ограничение контролирует максимальный объем виртуальной памяти, доступный процессу.
LimitAS=16G
# Ограничение на максимальное количество дочерних процессов, которые может создать данный процесс. Установлено на 1024.
# Это ограничение предотвращает создание чрезмерного количества дочерних процессов.
LimitNPROC=1024
# Ограничение на количество файловых блокировок, которые процесс может удерживать. Установлено на 512.
# Этот параметр предотвращает чрезмерное удержание блокировок файлов.
LimitLOCKS=512
# Ограничение на максимальное количество отложенных сигналов, разрешенных для пользователя, запускающего процесс. Установлено на 1024.
# Этот параметр контролирует количество сигналов, которые могут быть отложены для процесса.
LimitSIGPENDING=1024
# Ограничение на размер очередей сообщений, доступных процессу. Установлено на 8192 байта.
# Этот параметр контролирует объем памяти, выделенной для очередей сообщений.
LimitMSGQUEUE=8192
# Устанавливает лимит для значения приоритета (niceness) процесса. Установлено на 10.
# Этот параметр определяет, насколько процесс может снизить свой приоритет.
LimitNICE=10
# Устанавливает максимальный приоритет для процессов реального времени. Установлено на 20.
# Этот параметр контролирует максимальный приоритет, который процесс может получить в реальном времени.
LimitRTPRIO=20
# Ограничение на максимальное время выполнения в реальном времени, разрешенное для процесса. Установлено на 1 секунду.
# Этот параметр определяет, сколько времени процесс может выполнять операции реального времени.
LimitRTTIME=1s
[Install]
WantedBy=multi-user.target
Спасибо за внимание к материалу! Надеюсь, информация оказалась полезной для вас! Поздравляю с новым достижением!
Если материал оказался полезным и вы хотите поддержать мою работу, буду рад вашему донату. Любая помощь вдохновляет на создание нового контента! Спасибо за вашу поддержку!
ПОЛЕЗНЫЕ ССЫЛКИ
В этом ОГЛАВЛЕНИИ собраны и структурированы все материалы.
About & Contact || Услуги || Donate || Отказ от ответственности | ©