Службы и журналы на VPS: systemctl и journalctl

Что такое служба

Служба (сервис) это программа, которая работает в фоне и запускается вместе с системой: веб-сервер, база данных, SSH. В Ubuntu ими управляет systemd. Команда systemctl запускает и останавливает службы, а journalctl читает их журналы. Имя службы пишут без суффикса .service, например nginx или ssh.

Команды ниже вводите на сервере через sudo. Служба nginx взята как пример, подставьте свою.

Управление службой

Все команды этой статьи мы выполнили 6 октября 2026 года на VPS с Ubuntu 24.04, включая свой unit-файл из последнего раздела: служба запустилась, а после принудительного завершения процесса systemd сам поднял её через пять секунд.

sudo systemctl status nginx

Показывает состояние: active (running) значит работает, failed значит упала. Внизу выводятся последние строки журнала. Выход из просмотра клавишей q.

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx

start запускает службу, stop останавливает, restart перезапускает целиком, reload просит перечитать настройки без остановки (поддерживают его не все службы).

sudo systemctl enable nginx
sudo systemctl disable nginx
sudo systemctl enable --now nginx

enable включает автозапуск при загрузке системы, но не запускает службу сейчас. disable убирает автозапуск. enable --now делает и то и другое сразу.

Осторожно со службой ssh: если остановить её (stop) или сломать её настройки перед перезапуском, вы потеряете доступ к серверу и будете заходить через консоль в панели хостера. Перед restart ssh проверьте настройки командой sudo sshd -t и держите текущую сессию открытой.

Чтобы увидеть все упавшие службы разом:

systemctl --failed

Почему служба упала

Читайте журнал службы:

sudo journalctl -u nginx -n 50 --no-pager

-u nginx отбирает записи этой службы, -n 50 выводит последние 50 строк, --no-pager печатает всё сразу, без постраничного просмотра. Причина обычно в последних строках: занятый порт, ошибка в настройках, нет файла.

Другие полезные варианты:

sudo journalctl -u nginx -f
sudo journalctl -u nginx --since "1 hour ago"
sudo journalctl -u nginx --since today -p err
sudo journalctl -b

-f следит за журналом в реальном времени (выход Ctrl+C). --since "1 hour ago" показывает записи за последний час. --since today -p err оставляет записи за сегодня уровня «ошибка» и выше. -b показывает журнал с последней загрузки системы.

Журнал ядра, где видны, например, убитые из-за нехватки памяти процессы:

sudo journalctl -k

-k выводит только сообщения ядра. Как по ним понять нехватку ресурсов, написано в статье как понять, что серверу не хватает ресурсов.

Сколько места занимают журналы

journalctl --disk-usage

Показывает, сколько места занимают журналы на диске. Если они разрослись, их можно урезать:

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=2weeks

Первая команда удаляет старые записи, пока общий размер не станет не больше 200 МБ. Вторая удаляет записи старше двух недель. Удалённое не вернуть, так что сначала убедитесь, что старые записи вам не нужны.

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

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/size.conf

Первая команда создаёт каталог для своих настроек (если его нет), вторая открывает в нём файл. Внутри:

[Journal]
SystemMaxUse=200M

SystemMaxUse ограничивает, сколько места журналы могут занять на диске. Примените настройку:

sudo systemctl restart systemd-journald

Команда перезапускает службу журналирования. Значение 200 МБ взято как пример, подберите по размеру диска.

Свой unit-файл: бот или приложение как служба

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

sudo nano /etc/systemd/system/mybot.service

Внутри (пути и пользователя подставьте свои):

[Unit]
Description=My Telegram bot
After=network-online.target
Wants=network-online.target

[Service]
User=deploy
WorkingDirectory=/opt/mybot
ExecStart=/opt/mybot/venv/bin/python bot.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

В разделе [Unit] описание и условие запуска после появления сети. В [Service]: User задаёт пользователя, под которым работает программа (не root), WorkingDirectory рабочую папку, ExecStart полную команду запуска (путь к программе указывают целиком), Restart=on-failure перезапуск при сбое, RestartSec=5 паузу в 5 секунд. WantedBy=multi-user.target включает службу в обычную загрузку.

Затем:

sudo systemctl daemon-reload
sudo systemctl enable --now mybot
sudo systemctl status mybot

daemon-reload заставляет systemd перечитать файлы служб, enable --now включает автозапуск и запускает службу, status проверяет результат. Если служба упала, смотрите journalctl -u mybot -n 50. Подробно о боте на сервере: сервер для Telegram-бота.

Что делать дальше

Освоив эти команды, вы сможете сами разбираться со сбоями на сервере. Настройте резервные копии и файрвол. Если для проекта нужен сервер, откройте подбор VPS или страницу VPS для Telegram-бота.