Служба приложения и её журнал

Оглавление серии

Фоновое задание из прошлого урока принадлежало нашему терминалу. Для веб-приложения требуется более устойчивый договор: кто его запускает, из какого каталога, с какими настройками и что происходит после завершения. В профиле лаборатории эту связь задаёт systemd. Имя deskqueue.service объединит конфигурацию, процесс и записи журнала, но не будет означать, что приложение автоматически готово обслуживать любые запросы.

Откройте config/deskqueue.service и SERVICE-PREREQUISITES.md. Это подготовленные файлы, а не установленная служба. Для самостоятельного повторения нужны полные серверные файлы состояния 20 курса Node.js, его зависимости, схема PostgreSQL, отдельный аккаунт deskqueue, каталог загрузок и настоящая конфигурация подключения. Без этих предпосылок можно изучить файл, но нельзя ожидать успешного запуска.

Программа получает точный контекст

Главная часть конфигурации связывает пользователя, рабочий каталог и исполняемый файл. В нашем серверном проекте вход называется server.js и находится в корне выпуска. Путь /usr/bin/node в шаблоне является примером: замените его на подтверждённый абсолютный путь Node 24 LTS своей лаборатории. Результат command -v node из первого урока помогает сделать этот выбор.

[Service]
Type=exec
User=deskqueue
Group=deskqueue
WorkingDirectory=/srv/deskqueue/current
EnvironmentFile=/etc/deskqueue/deskqueue.env
ExecStart=/usr/bin/node /srv/deskqueue/current/server.js
Restart=on-failure
RestartSec=5s

systemd не запускает каждую строку как обычную команду интерактивной Bash. Не добавляйте в ExecStart случайные перенаправления и цепочки оболочки, ожидая привычного поведения. Сам процесс получает заданный рабочий каталог и переменные. Если приложение раньше зависело от вашего .bashrc, служба может проявить это скрытое условие. Лучше явно описать необходимый контекст, чем копировать настройки человеческого сеанса.

Тип exec позволяет связать успех начального запуска с выполнением указанной программы. Он всё равно не доказывает доступность базы и корректность ответов API. Политика on-failure задаёт перезапуск при определённых неудачных завершениях; это не лечение неверного пароля или отсутствующей схемы. В справке systemd.service описан жизненный цикл такой службы.

Конфигурация и место записи

В deskqueue.env.example перечислены PORT, DATABASE_URL, JWT_SECRET и UPLOAD_DIR. Все значения подключения и ключа являются заглушками. Настоящий файл создаётся отдельно в /etc/deskqueue/deskqueue.env; его содержимое не должно попадать в диагностический пакет. Переменная JWT_SECRET должна соответствовать формату серверного курса, поэтому произвольное слово из примера не считается готовым ключом.

Выпуск находится в /srv/deskqueue/current, а загруженные файлы — в /srv/deskqueue/shared/uploads. Это разделение позволяет заменить программный выпуск, сохраняя пользовательские вложения. В полном шаблоне служба получает запись только в выделенный путь, а системные и домашние каталоги ограничиваются. Договор требует существования нужных папок и подходящих владельцев; название параметра само не создаёт их.

Настройка PrivateTmp даёт службе отдельное представление временного каталога. Поэтому файл, найденный оператором в обычном /tmp, не обязан быть тем же объектом, который видит приложение. Если диагностика зависит от временных данных, учитывайте изоляцию. Такие ограничения полезны, когда их действие понятно; добавление множества параметров без знания файловых потребностей может просто запретить нужную операцию.

Если служба завершается сразу при запуске, сравните три отдельных предпосылки: бинарный файл Node действительно существует, пользователь может пройти каталог выпуска, а приложение получает требуемые значения конфигурации. Сообщение о неверном формате JWT_SECRET относится к проверке приложения; оно не исправляется разрешением записи в системную папку. Ошибка открытия server.js, напротив, направляет нас к пути и доступу. Такой разбор позволяет сохранить полезные ограничения и исправить конкретный договор вместо отключения всех защитных параметров сразу.

Установлено, включено и активно

После подготовки отдельного стенда файл службы может быть размещён в /etc/systemd/system/deskqueue.service. Изменение файла и перечитывание конфигурации менеджером — разные действия. daemon-reload перечитывает описания, а start запускает выбранную службу. enable связывает её с автоматическим запуском согласно разделу Install и сам по себе не заменяет текущий запуск.

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

systemctl status deskqueue.service --no-pager
systemctl show deskqueue.service -p ActiveState -p SubState -p MainPID -p ExecMainStatus

Если служба отсутствует, это ожидаемый исход незавершённой установки. Если она загружена, но неактивна, рассмотрите причину и журнал. Поля MainPID и ExecMainStatus дают конкретные признаки; они не заменяют проверку приложения. Сравнивайте найденный процесс с описанным выпуском, чтобы не принять старый экземпляр за результат новой конфигурации.

Журнал ограничиваем вопросом

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

journalctl -u deskqueue.service --since '-15 min' -n 100 --no-pager -o short-iso

Результат показывает доступные записи выбранной службы в ограниченной области. В справке journalctl описаны фильтры и форматы вывода. Пустой результат может означать отсутствие записей в периоде, недостаточный доступ или особенности хранения. Он не доказывает отсутствие ошибки приложения. Сначала уточните, где процесс вообще пишет свои сообщения.

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

Активность и готовность API

Серверный пример имеет два адреса: /health сообщает о процессе, /ready учитывает готовность и доступность базы. Служба может быть active, но второй адрес вернёт 503. Это осмысленное состояние: менеджер наблюдает процесс, а приложение сообщает, способен ли сейчас выполнить работу. В следующем уроке свяжем оба признака с сетевым адресом и портом.

В evidence/service.md запишите выпуск, состояние, найденный PID и выбранный интервал журнала. Если возникает повторный перезапуск, сначала изучите первое сообщение об отказе и конфигурационные предпосылки. Перезапуск не исправляет постоянную ошибку ввода. Результат урока — понятный договор службы и последовательность её наблюдения, а не утверждение, что подготовленный файл уже успешно установлен.