#Симптомы и условия возникновения
После обновления Node.js запуск вручную работает, а systemd, cron, редактор или сборщик продолжает обращаться к старому пути node и получает ENOENT/203/EXEC либо запускает старую версию. Для начала проверьте используемую версию среды и точный текст ошибки на копии проекта, не меняя рабочий сервер.
#Причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Старый абсолютный путьВ этой ситуации наблюдается конкретный диагностический признак. Сопоставьте его с журналом ошибки и результатом соответствующей проверки, прежде чем выбирать исправление. | ExecStart ссылается на удалённый файл Node | Уточнить действительный бинарник и настроить службу. |
| Разные PATHВ этой ситуации наблюдается конкретный диагностический признак. Сопоставьте его с журналом ошибки и результатом соответствующей проверки, прежде чем выбирать исправление. | which node в терминале отличается от окружения службы | Использовать проверенный абсолютный путь. |
| Менеджер версий под личным аккаунтомВ этой ситуации наблюдается конкретный диагностический признак. Сопоставьте его с журналом ошибки и результатом соответствующей проверки, прежде чем выбирать исправление. | nvm работает в интерактивном shell, не в systemd | Установить и закрепить доступный службе runtime. |
#Пошаговая диагностика и решение
- 1. Зафиксируйте сообщение службыЕсли ошибка в systemd — в терминале администратора службы запросите
systemctl status имя.serviceиjournalctl -u имя.service -n 30. Найдите ENOENT или status=203/EXEC; не начинайте с правки PATH.Linux · Терминал (Bash)КомандаLinux, замените ИМЯ.service на свою службу; чтение статуса обычно доступно без sudo.systemctl status ИМЯ.service --no-pager
- 2. Узнайте действительный Node у пользователя приложенияВ интерактивном сеансе нужного пользователя выполните
command -v node, затемnode -p "process.execPath"иnode -v. Это покажет версию и абсолютный путь;whichсам по себе может не отражать запуск из другой среды.Linux · Терминал (Bash)КомандаВ терминале Linux от имени пользователя службы: сначала абсолютный путь к Node.js, затем его версия. Обе команды только читают сведения.node -p "process.execPath"node -v
- 3. Сверьте файл службыВыполните
systemctl cat ИМЯ.service, проверьте ExecStart, User, WorkingDirectory и Environment. Не меняйте прямой файл из /lib/systemd/system: изменения могут исчезнуть после обновления пакета.
- 4. Проверьте доступность двоичного файлаПроверьте существование полного пути через
ls -l /путь/к/node. Если это ссылка, выясните, куда она ведёт. Не используйте устаревшую версию только для того, чтобы подавить ошибку.
- 5. Исправьте путь в управляемой настройке службыПри наличии прав администратора откройте
sudo systemctl edit ИМЯ.serviceи задайте override для ExecStart с новой абсолютной командой, предварительно очистив старую директиву. Пользователь, каталог и аргументы запуска должны остаться прежними.
- 6. Перечитайте конфигурацию и проверьтеПосле сохранения выполните
sudo systemctl daemon-reloadи только в окно обслуживанияsudo systemctl restart ИМЯ.service. Проверьтеstatus, журнал и ответ приложения. Если запуск неуспешен, восстановите исходный override.
- 7. Проверьте сборщик и планировщик отдельноДля Windows PowerShell используйте
Get-Command node, а для Планировщика задач — полный путь кnode.exeв поле «Программа или сценарий». Учитывайте рабочую папку задания; разные причины не устраняются одной настройкой.
#Как проверить результат и что делать, если не помогло
Служба и ручной запуск используют одинаковую предусмотренную версию Node, команда ExecStart существует и приложение отвечает после перезапуска.
Если неисправность повторилась, выпишите первый код ошибки и действие, на котором она возвращается. Сравните версию Node.js/npm, рабочий каталог, настройки процесса и журнал тестового запуска. Откатите только внесённые изменения из предварительно сохранённой копии, затем разберите причину на отдельной среде.