⚙️ forever – Process Manager simple pour Node.js

Qu'est-ce que forever ?

forever est un gestionnaire de processus (Process Manager) en ligne de commande (CLI), simple et léger, conçu pour les scripts Node.js.

C'est un des "ancêtres" des process managers Node.js (avec nodemon). Son objectif principal est de s'assurer qu'un script (ex: un serveur web) reste "vivant" (Keep-Alive) en production.

Fonctionnement (Watchdog)

forever lance votre script (ex: app.js) en tant que processus enfant (child process), et se met en mode "daemon" (arrière-plan).

Il "surveille" (watch) ce processus enfant. Si le processus enfant crashe (se termine avec un code d'erreur non-zéro), forever le redémarre automatiquement.

Lancer une application en production avec node app.js & (ou npm start &) est une très mauvaise pratique.

forever est le "pionnier", mais PM2 et Supervisor sont des solutions plus robustes.

Verdict : forever est suffisant pour un petit script simple. Pour toute application Node.js de production (serveur web), PM2 est le standard.

La commande start lance le script en mode "daemon" (arrière-plan).

$ forever start app.js
warn:    --minUptime not set. Defaulting to: 1000ms
warn:    --spinSleepTime not set. Defaulting to: 1000ms
info:    Forever processing file: app.js
info:    Script TOTO added to list.

$ forever list
info:    Forever processes running
data:        uid  command       script  forever pid   id logfile                 uptime
data:    [0] TOTO /usr/bin/node app.js  23456   23458    /home/user/.forever/TOTO.log 1s

• uid : L'ID (nom) unique du processus (ici, TOTO, généré aléatoirement si --uid n'est pas défini).
• command : Le runtime (ex: node).
• script : Le script (app.js).
• forever pid : Le PID du daemon forever (parent).
• pid : Le PID du processus app.js (enfant).
• logfile : Le chemin vers le fichier de log (stdout/stderr).

forever list (ou forever ls) est l'équivalent de pm2 list ou supervisorctl status.

$ forever list
info:    Forever processes running
data:        uid  command       script    forever pid   id logfile                     uptime
data:    [0] api  /usr/bin/node api.js    23456   23458    /home/user/.forever/api.log   2d 5h 10m
data:    [1] bot  /usr/bin/node bot.js    23500   23502    /home/user/.forever/bot.log   1h 20m
data:    [2] old  /usr/bin/node old.js    0       0        /home/user/.forever/old.log   STOPPED

Analyse :

• [0] api : (ID 0, uid api) Tourne depuis 2 jours.
• [1] bot : (ID 1, uid bot) Tourne depuis 1h 20m.
• [2] old : (ID 2, uid old) Est STOPPED. (PID = 0).

forever stop arrête un processus (il reste dans la liste avec le statut STOPPED).

Méthodes d'identification

Vous pouvez stopper un processus de 4 manières :

# 1. Par l'Index (recommandé)
$ forever stop 0   (Arrête l'ID [0] de 'forever list')

# 2. Par le 'uid' (si défini, voir 5.2)
$ forever stop api

# 3. Par le nom du script
$ forever stop app.js

# 4. Par le PID (du 'child' (enfant))
$ forever stop 23458

forever restart est un "hard restart" (Stop + Start). Il ne fait pas de "Zero-Downtime reload" (comme PM2).

# Redémarre l'ID [0]
$ forever restart 0
info:    Stopping process: api
info:    Process api stopped
info:    Forever processing file: api.js
info:    Script api added to list.

# (Le PID va changer)

stopall

Arrête tous les processus RUNNING gérés par forever.

$ forever stopall
info:    Stopping all running processes
info:    Process api stopped
info:    Process bot stopped

restartall

Redémarre tous les processus RUNNING.

forever (comme supervisor) capture stdout (console.log) et stderr (console.error, exceptions) des processus enfants.

Emplacement par Défaut

Par défaut, il crée un fichier de log unique (qui combine stdout/stderr) dans ~/.forever/.

$ forever list
data:        uid  ...  logfile
data:    [0] api  ...  /home/ideo/.forever/api.log

Rotation : forever ne gère pas la rotation des logs (logrotate) nativement. Les fichiers .log peuvent devenir énormes.

La commande forever logs est l'équivalent de pm2 logs ou tail -f. Elle "stream" (affiche en temps réel) les logs.

# Streamer les logs d'un script (par index)
$ forever logs 0

# Streamer (tail) les logs (force -f)
$ forever logs 0 -f

# Streamer (par nom de script)
$ forever logs api.js

# Afficher les 100 dernières lignes (pas de stream)
$ forever logs 0 -n 100

Vous pouvez (devez) personnaliser les chemins de logs au lieu d'utiliser ~/.forever/.

Exemple (Production)

# (Lance api.js)
# (Ajoute les logs 'stdout' à api-out.log)
# (Ajoute les logs 'stderr' à api-err.log)
$ forever start -a -o /var/log/myapp/api-out.log \
                -e /var/log/myapp/api-err.log \
                app.js

L'option -w (ou --watch) est l'équivalent de nodemon.

forever va "surveiller" (watch) le dossier (watchDirectory) du script. Si un fichier (ex: app.js) est modifié (sauvegardé), forever redémarre (restart) automatiquement le processus.

# 1. Démarrer en mode "watch"
$ forever start -w app.js

# 2. (Modifier et sauvegarder app.js)
# (forever détecte le changement)
info:    Changes detected in /path/to/app.js. Restarting...
info:    Process app.js stopped
info:    Forever processing file: app.js
...

Attention : Ne jamais utiliser --watch en Production (sauf cas très spécifique). C'est un outil de Développement.

forever (comme PM2) peut être lancé avec un fichier de configuration (JSON) pour définir les options (IaC).

Fichier (config.json)

[
  {
    // (Process 1)
    "uid": "api-web",
    "script": "app.js",
    "watch": false,
    "logFile": "/var/log/myapp/api.log",
    "append": true,
    "max": 10,
    "minUptime": 5000
  },
  {
    // (Process 2)
    "uid": "worker",
    "script": "worker.js",
    "logFile": "/var/log/myapp/worker.log",
    "append": true
  }
]

Lancement (CLI)

# Démarrer TOUS les scripts du JSON
$ forever start config.json

# Stopper TOUS les scripts du JSON
$ forever stop config.json

forever peut être utilisé comme une bibliothèque (library) Node.js (forever-monitor) pour gérer des processus enfants depuis votre propre code.

const forever = require('forever-monitor');

// 1. Définir l'enfant (child)
const child = new (forever.Monitor)('mon_script_enfant.js', {
    max: 3,
    silent: false,
    args: ['--port=8080']
});

// 2. Événements (Events)
child.on('watch:restart', (info) => {
    console.log('Restarting script because ' + info.file + ' changed');
});

child.on('restart', () => {
    console.log('Forever restarting script for ' + child.times + ' time');
});

child.on('exit:code', (code) => {
    console.log('Script exited with code ' + code);
});

// 3. Démarrer
child.start();

C'est la limitation majeure de forever par rapport à PM2.

forever ne supporte pas le "Clustering" (Load Balancing) natif. Il n'a pas d'équivalent au pm2 start -i max.

Le Problème (Node.js Mono-Thread)

Si vous lancez forever start app.js sur un serveur à 16 Cœurs, votre application ne tournera que sur 1 Cœur, laissant 15 Cœurs (94% du serveur) inutilisés.

Contournement (Manuel)

Le seul moyen de contourner (maladroitement) est de lancer 16 copies manuelles (ou via JSON) sur 16 ports différents (8001, 8002...) et de mettre un Load Balancer (Nginx, HAProxy) en façade.

Conclusion : forever est obsolète pour les serveurs web Node.js. PM2 (2.3) gère cela nativement (via le module cluster de Node.js).

forever ne fournit pas d'utilitaire (comme pm2 startup) pour créer automatiquement un service de démarrage (systemd ou init.d).

Le Problème

Si vous lancez forever start app.js et que le serveur (VM) redémarre, vos applications sont DOWN. Le daemon forever lui-même n'a pas été relancé.

Solution (Manuelle)

Vous devez manuellement créer un service systemd (ou un crontab @reboot) pour lancer forever au démarrage.

Exemple (Crontab @reboot)

# (Exécuter 'crontab -e' pour l'utilisateur 'ideo')

# (Au redémarrage, lancer 'forever' pour
#  démarrer TOUS les scripts sauvegardés)
@reboot /usr/bin/forever startall

Exemple (systemd)

Créer un /etc/systemd/system/forever.service (Complexe).