Depuis que cet article a attiré beaucoup d'attention au fil des ans, j'ai énuméré les meilleures solutions par plate-forme au bas de cet article.
Message original:
Je veux que mon serveur node.js s'exécute en arrière-plan, c'est-à-dire que, lorsque je ferme mon terminal, je veux que mon serveur continue à fonctionner. Je l'ai googlé et est venu avec ce tutorial , mais cela ne fonctionne pas comme prévu. Ainsi, au lieu d'utiliser ce script démon, j'ai pensé que je venais d'utiliser la redirection de sortie (la partie 2>&1 >> file
), mais cela ne se termine pas non plus - je reçois une ligne vide dans mon terminal, comme si elle attendait une sortie/des erreurs.
J'ai également essayé de mettre le processus en arrière-plan, mais dès que je ferme mon terminal, le processus est également éliminé.
Alors, comment puis-je le laisser fonctionner quand j'éteins mon ordinateur local?
Les meilleures solutions:
Copier ma propre réponse depuis Comment exécuter une application Node.js en tant que processus propre?
2015 answer: presque toutes les distributions Linux sont livrées avec systemd, ce qui signifie que forever, les surveillances, etc. ne sont plus nécessaires - votre système d'exploitation gère déjà ces tâches.
Créez un fichier myapp.service
(en remplaçant «myapp» par le nom de votre application, bien évidemment):
[Unit]
Description=My app
[Service]
ExecStart=/var/www/myapp/app.js
Restart=always
User=nobody
# Note Debian/Ubuntu uses 'nogroup', RHEL/Fedora uses 'nobody'
Group=nogroup
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
WorkingDirectory=/var/www/myapp
[Install]
WantedBy=multi-user.target
Remarque si vous êtes nouveau sur Unix:/var/www/myapp/app.js
devrait avoir #!/usr/bin/env node
sur la toute première ligne.
Copiez votre fichier de service dans le /etc/systemd/system
.
Commencez avec systemctl start myapp
.
Activez-le au démarrage avec systemctl enable myapp
.
Voir les journaux avec journalctl -u myapp
Ceci est tiré de Comment nous déployons les applications de noeud sur Linux, édition 2018, qui inclut également des commandes permettant de générer un AWS/DigitalOcean/Azure CloudConfig pour créer des serveurs Linux/noeud (y compris le fichier .service
).
Vous pouvez utiliser Forever, un outil CLI simple pour vous assurer qu'un script de noeud donné est exécuté en permanence (c'est-à-dire pour toujours): https://www.npmjs.org/package/forever
UPDATE - Comme indiqué dans l’une des réponses ci-dessous, PM2 manque de fonctionnalités vraiment sympas pour toujours. Pensez à l'utiliser.
Réponse originale
Utilisez Nohup :
Nohup node server.js &
EDIT Je voulais ajouter que la réponse acceptée est vraiment la voie à suivre. J'utilise depuis toujours des instances qui doivent rester en place. J'aime bien faire npm install -g forever
donc c'est dans le chemin du nœud puis il suffit de faire forever start server.js
Ce n'est peut-être pas la méthode acceptée, mais je le fais avec un écran, surtout pendant le développement, car je peux le remonter et le berner si nécessaire.
screen
node myserver.js
>>CTRL-A then hit D
L'écran se détachera et survivra à votre déconnexion. Ensuite, vous pouvez le récupérer en faisant screen -r. Hit le manuel de l'écran pour plus de détails. Vous pouvez nommer les écrans et ainsi de suite si vous le souhaitez.
2016 Update: La série node-windows/mac/linux utilise une API commune à tous les systèmes d'exploitation. Il s'agit donc d'une solution absolument pertinente. Toutefois; node-linux génère des fichiers systemv init. Alors que la popularité de systemd ne cesse de croître, il s’agit en réalité d’une meilleure option sous Linux. Les relations publiques sont les bienvenues si quelqu'un veut ajouter le support systemd à node-linux :-)
_ {Discussion d'origine: _
C'est un très vieux fil maintenant, mais node-windows fournit un autre moyen de créer des services d'arrière-plan sous Windows. Il est vaguement basé sur le concept nssm
consistant à utiliser un wrapper exe
autour de votre script de noeud. Toutefois; il utilise winsw.exe
à la place et fournit un wrapper de nœud configurable pour un contrôle plus granulaire du démarrage/arrêt du processus en cas d'échec. Ces processus sont disponibles comme n'importe quel autre service:
Le module prend également en compte certains événements:
La démonisation de votre script s'effectue par le biais de code. Par exemple:
var Service = require('node-windows').Service;
// Create a new service object
var svc = new Service({
name:'Hello World',
description: 'The nodejs.org example web server.',
script: 'C:\\path\\to\\my\\node\\script.js'
});
// Listen for the "install" event, which indicates the
// process is available as a service.
svc.on('install',function(){
svc.start();
});
// Listen for the "start" event and let us know when the
// process has actually started working.
svc.on('start',function(){
console.log(svc.name+' started!\nVisit http://127.0.0.1:3000 to see it in action.');
});
// Install the script as a service.
svc.install();
Le module prend en charge des choses telles que le redémarrage des commandes (de sorte que les mauvais scripts ne nuisent pas votre serveur) et des intervalles croissants entre les redémarrages.
Étant donné que les services noeud-fenêtres fonctionnent comme les autres, il est possible de gérer/surveiller le service avec le logiciel que vous utilisez déjà.
Enfin, il n'y a pas de dépendances make
. En d'autres termes, un simple npm install -g node-windows
fonctionnera. Vous n'avez pas besoin de Visual Studio, .NET ou de la magie node-gyp pour l'installer. En outre, il s'agit MIT et d'une licence BSD.
En toute transparence, je suis l'auteur de ce module. Il a été conçu pour soulager la douleur subie par le PO, mais avec une intégration plus étroite dans les fonctionnalités déjà fournies par le système d’exploitation. J'espère que les futurs téléspectateurs avec cette même question le trouveront utile.
UPDATE: j'ai mis à jour pour inclure la dernière de pm2:
dans de nombreux cas d'utilisation, l'utilisation d'un service systemd est le moyen le plus simple et le plus approprié de gérer un processus de noeud. Pour ceux qui exécutent de nombreux processus de noeuds ou des microservices de noeuds indépendants dans un seul environnement, pm2 est un outil plus complet.
https://github.com/unitech/pm2
pm2 monit
ou liste de processus avec pm2 list
pm2 logs
- Comportement comportement
- Support de carte source
- Compatible PaaS
- Regarder et recharger
- Système de module
- Max rechargement de la mémoire
- Mode cluster
- Rechargement à chaud
- Flux de travail de développement
- Scripts de démarrage
- Achèvement automatique
- Workflow de déploiement
- Surveillance Keymetrics
- API
Si vous utilisez OSX, le moyen le plus simple de générer un processus système réel consiste à utiliser launchd
pour le lancer.
Construisez un plist comme celui-ci et placez-le dans le répertoire/Bibliothèque/LaunchDaemons avec le nom top-level-domain.your-domain.application.plist
(vous devez être root pour le placer):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.Apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>top-level-domain.your-domain.application</string>
<key>WorkingDirectory</key>
<string>/your/preferred/workingdirectory</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/node</string>
<string>your-script-file</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
</dict>
</plist>
Une fois terminé, lancez ceci (en tant que root):
launchctl load /Library/LaunchDaemons/top-level-domain.your-domain.application.plist
launchctl start top-level-domain.your-domain.application
et vous courez.
Et vous continuerez à courir après un redémarrage.
Pour plus d’informations sur la pliste, consultez la page de manuel ici: https://developer.Apple.com/library/mac/documentation/Darwin/Reference/Manpages/man5/launchd.plist.5.html
J'utilise simplement le module daemon npm:
var daemon = require('daemon');
daemon.daemonize({
stdout: './log.log'
, stderr: './log.error.log'
}
, './node.pid'
, function (err, pid) {
if (err) {
console.log('Error starting daemon: \n', err);
return process.exit(-1);
}
console.log('Daemonized successfully with pid: ' + pid);
// Your Application Code goes here
});
Dernièrement, j'utilise également mon (1) de TJ Holowaychuk pour démarrer et gérer des applications de nœud simples.
Si vous voulez simplement exécuter le script sans interruption jusqu'à la fin, vous pouvez utiliser nohop
comme déjà mentionné dans les réponses ici. Cependant, aucune des réponses ne fournit une commande complète qui enregistre également stdin
et stdout
.
Nohup node index.js >> app.log 2>&1 &
>>
signifie ajouter à app.log
.2>&1
s'assure que les erreurs sont également envoyées à stdout
et ajoutées au app.log
.&
s'assure que votre terminal actuel est déconnecté de la commande afin que vous puissiez continuer à travailler. Si vous souhaitez exécuter un serveur de nœud (ou quelque chose qui devrait être redémarré au redémarrage du serveur), vous devez utiliser systemd/systemctl .
J'utilise Supervisor pour le développement. Ça fonctionne. Lorsque vous apportez des modifications à un fichier .js, Supervisor redémarre automatiquement votre application avec ces modifications chargées.
Voici un lien vers sa page Github
Installer:
Sudo npm install supervisor -g
Vous pouvez facilement regarder d'autres extensions avec -e. Une autre commande que j'utilise souvent est -i pour ignorer certains dossiers.
Vous pouvez utiliser Nohup et supervisor pour que votre application de noeud s'exécute en arrière-plan, même après votre déconnexion.
Sudo Nohup supervisor myapp.js &
Essayez d’exécuter cette commande si vous utilisez Nohup -
Nohup npm start 2>/dev/null 1>/dev/null&
Vous pouvez également utiliser pour toujours pour démarrer le serveur
forever start -c "npm start" ./
PM2 prend également en charge npm start
pm2 start npm -- start
Node.js en tant que service d'arrière-plan dans WINDOWS XP
Installation:
Créez c:\node\helloworld.js
// http://howtonode.org/hello-node
var http = require('http');
var server = http.createServer(function (request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end("Hello World\n");
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
Ouvrez la console de commande et tapez ce qui suit (setx uniquement si le Kit de ressources est installé)
C:\node> set path=%PATH%;%CD%
C:\node> setx path "%PATH%"
C:\node> set NODE_PATH="C:\Program Files\nodejs\node_modules"
C:\node> git config --system http.sslcainfo /bin/curl-ca-bundle.crt
C:\node> git clone --recursive git://github.com/isaacs/npm.git
C:\node> cd npm
C:\node\npm> node cli.js install npm -gf
C:\node> cd ..
C:\node> nssm.exe install node-helloworld "C:\Program Files\nodejs\node.exe" c:\node\helloworld.js
C:\node> net start node-helloworld
Un lot intéressant est de créer c:\node\ServiceMe.cmd
@echo off
nssm.exe install node-%~n1 "C:\Program Files\nodejs\node.exe" %~s1
net start node-%~n1
pause
La gestion des services:
La réponse acceptée est probablement la meilleure réponse de production, mais pour un piratage rapide en tant que développeur, j'ai trouvé ceci:
nodejs scriptname.js &
ne fonctionnait pas, car nodejs semblait engloutir le &, ce qui ne m'a pas permis de continuer à utiliser le terminal sans scriptname.js en train de mourir.
Mais j'ai mis nodejs scriptname.js
dans un fichier .sh, et Nohup sh startscriptname.sh &
a fonctionné.
Ce n’est certainement pas une opération de production, mais cela résout le problème "Je dois continuer à utiliser mon terminal et je ne veux pas démarrer 5 terminaux différents".
Si vous utilisez nodejs sur le serveur Linux, je pense que c'est la meilleure solution.
Créez un script de service et copiez-le dans /etc/init/nodejs.conf
service de démarrage: démarrage du service Sudo
arrêtez le service: sudo service nodejs stop
Sevice script
description "DManager node.js server - Last Update: 2012-08-06"
author "Pedro Muniz - [email protected]"
env USER="nodejs" #you have to create this user
env APPNAME="nodejs" #you can change the service name
env WORKDIR="/home/<project-home-dir>" #set your project home folder here
env COMMAND="/usr/bin/node <server name>" #app.js ?
# used to be: start on startup
# until we found some mounts weren't ready yet while booting:
start on started mountall
stop on shutdown
# Automatically Respawn:
respawn
respawn limit 99 5
pre-start script
Sudo -u $USER echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Starting" >> /var/log/$APPNAME.log
end script
script
# Not sure why $HOME is needed, but we found that it is:
export HOME="<project-home-dir>" #set your project home folder here
export NODE_PATH="<project node_path>"
#log file, grant permission to nodejs user
exec start-stop-daemon --start --make-pidfile --pidfile /var/run/$APPNAME.pid --chuid $USER --chdir $WORKDIR --exec $COMMAND >> /var/log/$APPNAME.log 2>&1
end script
post-start script
# Optionally put a script here that will notifiy you node has (re)started
# /root/bin/hoptoad.sh "node.js has started!"
end script
pre-stop script
Sudo -u $USER echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Stopping" >> /var/log/$APPNAME.log
end script
Mise à jour de juin 2017:
Solution pour Linux: (Red Hat). Les commentaires précédents ne fonctionnent pas pour moi . Cela fonctionne pour moi sur Amazon Web Service - Red Hat 7. J'espère que cela fonctionne pour quelqu'un.
A. Create the service file
Sudo vi /etc/systemd/system/myapp.service
[Unit]
Description=Your app
After=network.target
[Service]
ExecStart=/home/ec2-user/meantodos/start.sh
WorkingDirectory=/home/ec2-user/meantodos/
[Install]
WantedBy=multi-user.target
B. Create a Shell file
/home/ec2-root/meantodos/start.sh
#!/bin/sh -
Sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 8080
npm start
then:
chmod +rx /home/ec2-root/meantodos/start.sh
(to make this file executable)
C. Execute the Following
Sudo systemctl daemon-reload
Sudo systemctl start myapp
Sudo systemctl status myapp
(If there are no errors, execute below. Autorun after server restarted.)
chkconfig myapp -add
utilisez nssm la meilleure solution pour Windows, il suffit de télécharger nssm , ouvrez cmd dans le répertoire nssm et tapez
nssm install <service name> <node path> <app.js path>
eg: nssm install myservice "C:\Program Files\nodejs" "C:\myapp\app.js"
cela installera un nouveau service Windows qui sera répertorié à l'adresse services.msc. Vous pourrez alors démarrer ou arrêter le service. Ce service démarrera automatiquement et vous pourrez configurer son redémarrage en cas d'échec.
Pour compléter les différentes options suggérées, voici une dernière: la commande daemon
dans GNU/Linux, que vous pouvez lire ici: http://libslack.org/daemon/manpages/daemon.1.html . (excuses si cela est déjà mentionné dans l'un des commentaires ci-dessus).
quelqu'un at-il remarqué une erreur triviale de la position de "2> & 1"?
2>&1 >> file
devrait être
>> file 2>&1
Découvrez la fugue! Outre le lancement de nombreux travailleurs, vous pouvez aussi diaboliser votre processus de nœud!
J'utilise tmux pour un environnement de développement à plusieurs fenêtres/volets sur des hôtes distants. C'est très simple de détacher et de garder le processus en arrière-plan. Regardez tmux
Pour les personnes utilisant les versions plus récentes du module daemon npm - vous devez transmettre des descripteurs de fichier au lieu de chaînes:
var fs = require('fs');
var stdoutFd = fs.openSync('output.log', 'a');
var stderrFd = fs.openSync('errors.log', 'a');
require('daemon')({
stdout: stdoutFd,
stderr: stderrFd
});
PM2 est un gestionnaire de processus de production pour les applications Node.js avec un équilibreur de charge intégré. Il vous permet de garder les applications en vie, de les recharger sans interruption et de faciliter les tâches courantes d'administration système . https://github.com/Unitech/pm2
Je suis surpris que personne n'ait mentionné Guvnor
J'ai toujours essayé, pm2, etc. Mais, en ce qui concerne le contrôle solide et les mesures de performance basées sur le Web, j'ai trouvé Guvnor être de loin le meilleur. De plus, il est également entièrement opensource.
Edit: Cependant, je ne suis pas sûr que cela fonctionne sous Windows. Je ne l'ai utilisé que sur Linux.
Cette réponse est assez tardive pour le parti, mais j’ai trouvé que la meilleure solution consistait à écrire un script Shell qui utilisait les commandes screen -dmS
et Nohup
.
screen -dmS newScreenName Nohup node myserver.js >> logfile.log
J'ajoute également le bit >> logfile
à la fin afin de pouvoir facilement enregistrer les instructions de noeud console.log()
.
Pourquoi ai-je utilisé un script shell? J'ai également ajouté une instruction if vérifiant si le processus node myserver.js
était déjà en cours d'exécution.
De cette façon, j'ai pu créer une seule option de ligne de commande qui me permet de garder le serveur en activité et de le redémarrer lorsque j'ai apporté des modifications, ce qui est très utile pour le développement.