Как запустить Node.js в качестве фонового процесса и не умереть?

Ответ 1

Простое решение (если вы не хотите возвращаться к процессу, просто хотите, чтобы он продолжал работать):

nohup node server.js &

Мощное решение (позволяет вам повторно подключиться к процессу, если оно интерактивно):

screen

Затем вы можете отсоединить, нажав Ctrl + a + d, а затем присоединить обратно, запустив screen -r

Также рассмотрим более новую альтернативу экрану, tmux.

Ответ 2

nohup node server.js > /dev/null 2>&1 &

• nohup означает: не прекращайте этот процесс, даже когда стрит вырезается выкл.
• > /dev/null означает: stdout переходит в /dev/null (что является манекеном устройство, которое не записывает никакого вывода).
• 2>&1 означает: stderr также переходит к эталону (который уже перенаправлен на /dev/null). Вы можете заменить & 1 на путь файла, чтобы сохранить журнал ошибок, например: 2>/tmp/myLog
• & в конце означает: выполните эту команду в качестве фоновой задачи.

Ответ 3

Вы действительно должны попытаться использовать screen. Это немного сложнее, чем просто делать nohup long_running &, но понимать экран, как только вы больше не вернетесь.

Сначала начните сеанс экрана:

[email protected]:~$ screen

Запустите все, что хотите:

wget http://mirror.yandex.ru/centos/4.6/isos/i386/CentOS-4.6-i386-binDVD.iso

Нажмите ctrl + A, а затем d. Готово. Ваша сессия продолжается в фоновом режиме.

Вы можете перечислить все сеансы с помощью screen -ls и прикрепить к команде some screen -r 20673.pts-0.srv, где 0673.pts-0.srv - список записей.

Ответ 4

Это старый вопрос, но он занимает высокое место в Google. Я почти не могу поверить в самые высокие голосовые ответы, потому что запуск node.js-процесса внутри сеанса экрана с помощью & или даже с флагом nohup - все они - всего лишь обходные пути.

Специально решение screen/tmux, которое действительно должно рассматриваться как любительское решение. Экран и Tmux не предназначены для поддержания процессов, но для мультиплексирования терминальных сеансов. Это нормально, когда вы используете script на своем сервере и хотите отключиться. Но для сервера node.js вы не хотите, чтобы ваш процесс был присоединен к сеансу терминала. Это слишком хрупко. Чтобы поддерживать работу, вам необходимо демонтировать процесс!

Есть много хороших инструментов для этого.

PM2: http://pm2.keymetrics.io/

# basic usage
$ npm install pm2 -g
$ pm2 start server.js

# you can even define how many processes you want in cluster mode:
$ pm2 start server.js -i 4

# you can start various processes, with complex startup settings
# using an ecosystem.json file (with env variables, custom args, etc):
$ pm2 start ecosystem.json

Одно большое преимущество, которое я вижу в пользу PM2, заключается в том, что он может генерировать запуск системы script, чтобы процесс сохранялся между перезапусками:

$ pm2 startup [platform]

Где platform может быть ubuntu|centos|redhat|gentoo|systemd|darwin|amazon.

forever.js: https://github.com/foreverjs/forever

# basic usage
$ npm install forever -g
$ forever start app.js

# you can run from a json configuration as well, for
# more complex environments or multi-apps
$ forever start development.json

Инициировать скрипты:

Я не буду вдаваться в подробности о том, как написать init script, потому что я не эксперт в этой теме, и это слишком долго для этого ответа, но в основном это простые сценарии оболочки, вызванные по событиям ОС. Вы можете прочитать об этом здесь

Docker

Просто запустите свой сервер в контейнере Docker с опцией -d, и, вы, у вас есть демонаризованный сервер node.js!

Вот пример файла Dockerfile (из node.js официальное руководство):

FROM node:argon

# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Install app dependencies
COPY package.json /usr/src/app/
RUN npm install

# Bundle app source
COPY . /usr/src/app

EXPOSE 8080
CMD [ "npm", "start" ]

Затем создайте изображение и запустите контейнер:

$ docker build -t <your username>/node-web-app .
$ docker run -p 49160:8080 -d <your username>/node-web-app

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

Ответ 5

другое решение отменит задание

$ nohup node server.js &
[1] 1711
$ disown -h %1

Ответ 6

nohup позволит программе продолжить работу даже после того, как терминал погибнет. У меня на самом деле были ситуации, когда nohup препятствует правильному завершению сеанса SSH, поэтому вы также должны перенаправить ввод:

$ nohup node server.js </dev/null &

В зависимости от того, как настроен nohup, вам также может потребоваться перенаправить стандартный вывод и стандартную ошибку в файлы.

Ответ 7

У меня есть эта функция в моем файле rc оболочки, на основе ответа @Yoichi:

nohup-template () {
    [[ "$1" = "" ]] && echo "Example usage:\nnohup-template urxvtd" && return 0
    nohup "$1" > /dev/null 2>&1 &
}

Вы можете использовать его следующим образом:

nohup-template "command you would execute here"

Ответ 8

$ disown node server.js &

Он удалит команду из активного списка задач и отправит команду в фоновый режим

Ответ 9

Nohup и экран предлагают отличные решения для запуска Node.js в фоновом режиме. Node.js менеджер процессов (PM2) - удобный инструмент для развертывания. Установите его с помощью npm глобально в вашей системе:

npm install pm2 -g

для запуска приложения Node.js в качестве демона:

pm2 start app.js

Вы можете связать его с Keymetrics.io мониторингом SAAS, сделанным Unitech.

Ответ 10

Вы читали о команде nohup?

Ответ 11

Запуск команды в качестве системной службы на debian с помощью sysv init:

Скопируйте скелет script и адаптируйте его для своих нужд, вероятно, вам нужно всего лишь установить некоторые переменные. Ваш script наследует мелкие значения по умолчанию от /lib/init/init-d-script, если что-то не соответствует вашим потребностям - переопределите его в script. Если что-то пойдет не так, вы можете увидеть подробности в источнике /lib/init/init-d-script. Обязательные vars DAEMON и NAME. script будет использовать start-stop-daemon для запуска вашей команды, в START_ARGS вы можете определить дополнительные параметры start-stop-daemon для использования.

cp /etc/init.d/skeleton /etc/init.d/myservice
chmod +x /etc/init.d/myservice
nano /etc/init.d/myservice

/etc/init.d/myservice start
/etc/init.d/myservice stop

Вот как я запускаю некоторые вещи python для своей вики-вики:

...
DESC="mediawiki articles converter"
DAEMON='/home/mss/pp/bin/nslave'
DAEMON_ARGS='--cachedir /home/mss/cache/'
NAME='nslave'
PIDFILE='/var/run/nslave.pid'
START_ARGS='--background --make-pidfile --remove-pidfile --chuid mss --chdir /home/mss/pp/bin'

export PATH="/home/mss/pp/bin:$PATH"

do_stop_cmd() {
    start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
        $STOP_ARGS \
        ${PIDFILE:+--pidfile ${PIDFILE}} --name $NAME
    RETVAL="$?"
    [ "$RETVAL" = 2 ] && return 2
    rm -f $PIDFILE
    return $RETVAL
}

Помимо настройки vars мне пришлось переопределить do_stop_cmd, потому что python заменяет исполняемый файл, поэтому служба не останавливается должным образом.

Ответ 12

Помимо прохладных решений выше, я бы также упомянул о инструментах супервизора и monit, которые позволяют начать процесс, контролировать его присутствие и запускать его, если он умер. С помощью "monit" вы также можете запустить некоторые активные проверки, например, проверить, реагирует ли процесс на http-запрос

Ответ 13

Для Ubuntu я использую это:

(exec PROG_SH &>/dev/null &)

С уважением

Ответ 14

Попробуйте это для простого решения

cmd & exit