Wie kann man Node.js als Hintergrundprozess ausführen und niemals sterben?

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

1. Nohup bedeutet: Beenden Sie diesen Vorgang nicht, auch wenn die Stty abgeschnitten istoff.
2. > /dev/null bedeutet: stdout geht nach/dev/null (was ein Dummy-Gerät ist, das keine Ausgabe aufzeichnet).  
3. 2>&1 bedeutet: stderr geht auch zum stdout (der bereits zu /dev/null umgeleitet wurde). Sie können & 1 durch einen Dateipfad ersetzen, um ein Fehlerprotokoll zu führen, z. B .: 2>/tmp/myLog
4. & am Ende bedeutet: führe diesen Befehl als Hintergrundaufgabe aus.

Sie sollten wirklich versuchen, screen zu verwenden. Es ist etwas komplizierter als nur Nohup long_running &, aber wenn Sie den Bildschirm einmal verstehen, kommen Sie nie wieder zurück. 

Starten Sie zuerst Ihre Bildschirmsitzung:

[email protected]:~$ screen

Führen Sie alles aus, was Sie möchten:

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

Drücken Sie Strg + A und dann d. Erledigt. Ihre Sitzung läuft im Hintergrund weiter.

Sie können alle Sitzungen mit screen -ls auflisten und mit screen -r 20673.pts-0.srv-Befehl an einige anschließen, wobei 0673.pts-0.srv eine Eintragsliste ist.

Dies ist eine alte Frage, die aber bei Google einen hohen Stellenwert hat. Ich kann fast nicht an die Antworten mit den höchsten Stimmen glauben, weil das Ausführen eines node.js-Prozesses innerhalb einer Bildschirmsitzung, mit dem & oder sogar mit dem Nohup-Flag - alle - nur eine Problemumgehung sind.

Speziell die screen/tmux-Lösung, die eigentlich als amateur - Lösung betrachtet werden sollte. Screen und Tmux sind nicht dazu gedacht, Prozesse am Laufen zu halten, sondern für das Multiplexen von Terminalsitzungen. Es ist in Ordnung, wenn Sie ein Skript auf Ihrem Server ausführen und die Verbindung trennen möchten. Für einen node.js-Server möchten Sie jedoch nicht, dass Ihr Prozess an eine Terminalsitzung angehängt wird. Das ist zu zerbrechlich. Um die Dinge am Laufen zu halten, müssen Sie den Prozess daemonisieren!

Dafür gibt es viele gute Werkzeuge.

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

Ein großer Vorteil, den ich für PM2 sehe, ist, dass es das Systemstart-Skript generieren kann, damit der Prozess zwischen Neustarts bestehen bleibt:

$ pm2 startup [platform]

Dabei kann platformubuntu|centos|redhat|gentoo|systemd|darwin|Amazon sein.

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-Skripte:

Ich werde nicht ausführlich darauf eingehen, wie man ein Init-Skript schreibt, weil ich kein Experte für dieses Thema bin und es für diese Antwort zu lang wäre, aber im Grunde handelt es sich um einfache Shell-Skripts, die durch Betriebssystemereignisse ausgelöst werden. Sie können mehr darüber lesen hier

Docker:

Führen Sie Ihren Server einfach in einem Docker-Container mit der -d-Option aus und haben Sie mit voilá einen daemonisierten node.js Server!

Hier ist ein Beispiel Dockerfile (von node.js offizielle Anleitung ):

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" ]

Erstellen Sie dann Ihr Image und führen Sie Ihren Container aus:

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

Ich hoffe, das hilft jemandem, auf dieser Seite zu landen. Verwenden Sie immer das richtige Werkzeug für die Arbeit. Das erspart Ihnen viele Kopfschmerzen und über Stunden!

eine andere Lösung verweigerte den Job

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

Mit Nohup kann das Programm auch nach dem Tod des Terminals fortgesetzt werden. Ich hatte tatsächlich Situationen, in denen Nohup verhindert, dass die SSH-Sitzung korrekt beendet wird. Daher sollten Sie auch die Eingabe umleiten:

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

Abhängig von der Konfiguration von Nohup müssen Sie möglicherweise auch die Standardausgabe und den Standardfehler in Dateien umleiten.

Ich habe diese Funktion in meiner Shell-RC-Datei, basierend auf der Antwort von @ Yoichi:

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

Sie können es so verwenden:

Nohup-template "command you would execute here"

$ disown node server.js &

Der Befehl wird aus der aktiven Aufgabenliste entfernt und in den Hintergrund gesendet 

Nohup und Screen bieten hervorragende Lichtlösungen, um Node.js im Hintergrund auszuführen. Der Node.js-Prozessmanager ( PM2 ) ist ein praktisches Werkzeug für die Bereitstellung. Installieren Sie es mit npm global auf Ihrem System: 

npm install pm2 -g

so führen Sie eine Node.js-App als Daemon aus:

pm2 start app.js

Sie können es optional mit Keymetrics.io einem Überwachungs-SAAS von Unitech verknüpfen.

Haben Sie über den Befehl Nohup gelesen?

Für Ubuntu verwende ich folgendes:

(exec PROG_SH &>/dev/null &)

grüße

Befehl als Systemdienst unter Debian mit sysv init ausführen:

Kopieren Sie das Skelett-Skript und passen Sie es an Ihre Bedürfnisse an. Sie müssen wahrscheinlich nur einige Variablen festlegen. Ihr Skript erbt feine Standardwerte von /lib/init/init-d-script, falls etwas nicht Ihren Anforderungen entspricht - überschreiben Sie es in Ihrem Skript. Wenn etwas schief geht, können Sie Details in Quelle /lib/init/init-d-script sehen. Pflichtangaben sind DAEMON und NAME. Das Skript verwendet start-stop-daemon zur Ausführung Ihres Befehls. In START_ARGS können Sie zusätzliche Parameter für start-stop-daemon definieren.

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

So führe ich Python-Sachen für mein Wikimedia-Wiki aus:

...
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
}

Neben dem Setzen von vars musste ich do_stop_cmd überschreiben, da Python die ausführbare Datei ersetzt, sodass der Dienst nicht ordnungsgemäß angehalten wurde.

Abgesehen von den coolen Lösungen oben erwähnte ich auch Supervisord- und Überwachungs-Tools, die es ermöglichen, den Prozess zu starten, seine Anwesenheit zu überwachen und ihn zu starten, falls er stirbt. Mit 'monit' können Sie auch einige aktive Prüfungen durchführen, z. B. ob der Prozess auf die http-Anforderung antwortet

Versuchen Sie dies für eine einfache Lösung

cmd & exit