Accueil

Générateur Supervisor

Générateur de Configuration Linux Supervisord (supervisord.conf)

POSIX Anti-Zombie

Générez des blocs de configuration de programmes Supervisord prêts pour la production avec redémarrage automatique, multi-processus, redirection des logs et privilèges utilisateur.

Préréglages :
Commande et Exécution
Mise à l'échelle et Concurrence
Instances: 4
Cycle de Vie et Redémarrage
Signaux POSIX et Arbre de Processus
Journaux et Redirection de Flux
Variables d'Environnement
KEY="value"

Les retours à la ligne sont automatiquement convertis en syntaxe avec virgules.

Directives: 26•Procs: 4•Signal: SIGQUIT
User: www-data
; ==============================================================================
; Supervisord Program Configuration: laravel-worker
; Generated 100% Client-Side Private on ToolsAA
; Path: /etc/supervisor/conf.d/laravel-worker.conf (Ubuntu/Debian)
;   or: /etc/supervisord.d/laravel-worker.ini (CentOS/RHEL/Rocky)
; ==============================================================================

[program:laravel-worker]
command=php /var/www/laravel/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
process_name=%(program_name)s_%(process_num)02d
numprocs=4
directory=/var/www/laravel
user=www-data
umask=022
priority=999
autostart=true
autorestart=true
startsecs=1
startretries=3
stopsignal=QUIT
stopwaitsecs=3600
stopasgroup=true
killasgroup=true
redirect_stderr=true
stdout_logfile=/var/log/supervisor/laravel-worker.log
stdout_logfile_maxbytes=50MB
stdout_logfile_backups=5
environment=APP_ENV="production",CACHE_DRIVER="redis"
29 lines•944 chars•944 B
program
Concurrence de cluster
4 Processes

Load-balanced parallel execution pool

Protection anti-zombies
100% Contained

stopasgroup & killasgroup both active

Limite de rotation des logs
50MB × 5

Consommation disque plafonnée avec rotation automatique

Synthèse INI 100% dans le Navigateur

Aucun envoi vers un serveur externe. Vos paramètres système et variables d'environnement sont traités exclusivement en mémoire locale.

Contrôle des Processus Fils et Prévention des Zombies

Intègre stopasgroup et killasgroup pour garantir l'arrêt complet de tous les processus enfants (Celery, Gunicorn, Node) sans processus orphelins.

Compatibilité Linux Standard et Docker

Prêt pour les configurations Debian/Ubuntu /etc/supervisor/conf.d/, RHEL /etc/supervisord.d/, services systemd et conteneurs Docker.

Référence technique et guide d'architecture

Guide Développeur du Générateur de Configuration Supervisord Linux (supervisord.conf) — Guide de référence

Générez des blocs de configuration de programmes Supervisord prêts pour la production avec redémarrage automatique, multi-processus, redirection des logs et privilèges utilisateur.

Paramètres clés et contrôles

commandDirective

Ligne de commande complète à exécuter. Doit obligatoirement rester au premier plan sans se démoniser.

Par défaut : Requis
directoryDirective

Chemin absolu du répertoire de travail dans lequel basculer avant d'exécuter la commande.

Par défaut : /var/www/app
autostartDirective

Détermine si le programme doit démarrer automatiquement lors du lancement du démon supervisord.

Par défaut : true
autorestartDirective

Politique de redémarrage automatique ('true' toujours, 'false' jamais, 'unexpected' uniquement en cas de code d'erreur).

Par défaut : true
userDirective

Compte utilisateur UNIX non privilégié sous lequel le processus sera exécuté afin de révoquer les droits root.

Par défaut : www-data
numprocsDirective

Nombre d'instances de processus parallèles. Requiert le modèle %(process_num)s dans process_name si supérieur à 1.

Par défaut : 1
stopasgroupDirective

Transmet les signaux d'arrêt à l'ensemble du groupe de processus pour arrêter proprement tous les processus enfants.

Par défaut : true
stdout_logfileDirective

Chemin de destination des logs de sortie standard (stdout) avec gestion de la rotation automatique.

Par défaut : /var/log/supervisor/%(program_name)s.out.log

Conseils de pro et bonnes practices

Supervisord supervise l'état des

Supervisord supervise l'état des services via leur PID. Les processus doivent impérativement s'exécuter au premier plan (ex : 'daemon off;' pour Nginx, pas de drapeau --daemon avec Gunicorn).

Pour les applications comme Node.js

Pour les applications comme Node.js, Celery ou Gunicorn qui instancient des processus enfants, définissez 'stopasgroup=true' et 'killasgroup=true' afin d'empêcher les processus zombies à l'arrêt.

Évitez d'utiliser 'supervisorctl

Évitez d'utiliser 'supervisorctl reload' en production. Privilégiez 'supervisorctl reread' pour analyser les fichiers modifiés puis 'supervisorctl update' pour n'appliquer les changements qu'aux programmes concernés.

Lors de l'utilisation de 'numprocs=4'

Lors de l'utilisation de 'numprocs=4', définissez 'process_name=%(program_name)s_%(process_num)02d'. Chaque worker disposera ainsi d'un nom unique et de flux de logs dédiés.

Pièges courants et dépannage

Le processus passe en état FATAL avec l'erreur 'Exited too quickly'

Cela se produit si l'application s'exécute en arrière-plan ou plante immédiatement au lancement. Vérifiez l'exécution au premier plan, examinez les logs stderr et définissez 'startsecs=5' pour accorder un délai de démarrage.

SPAWNERR: Impossible de rétrograder les privilèges vers l'utilisateur indiqué

Vérifiez que l'utilisateur spécifié dans 'user=' existe bien dans /etc/passwd et dispose des droits de lecture/exécution sur le binaire ainsi que des droits d'écriture sur le répertoire de travail et les dossiers de logs.

Des processus enfants continuent de tourner après l'arrêt du programme

Ajoutez 'stopasgroup=true' et 'killasgroup=true' dans la section [program:name]. Sans ces paramètres, seul le processus parent reçoit le signal d'interruption.

Foire aux questions (FAQ)

Où doivent être enregistrés les fichiers de configuration de programmes sous Linux ?▼

Sur Debian et Ubuntu, les configurations de programmes se placent dans /etc/supervisor/conf.d/*.conf. Sur CentOS, RHEL et Rocky Linux, elles résident généralement dans /etc/supervisord.d/*.ini ou *.conf, incluses via la directive [include] du fichier principal supervisord.conf.

Comment appliquer des modifications de configuration sans redémarrer tous les services ?▼

Lancez 'supervisorctl reread' pour scanner les nouvelles configurations, puis 'supervisorctl update'. Seuls les services créés ou modifiés seront rechargés ou démarrés, sans aucune interruption pour les autres services en cours d'exécution.

Comment exécuter des environnements virtuels Python (venv) ou des versions Node.js (nvm) ?▼

Supervisord ne charge pas les profils shell (.bashrc). Renseignez directement le chemin absolu vers l'exécutable dans la directive command, par exemple : /home/user/venv/bin/gunicorn app:app ou /home/user/.nvm/versions/node/v20.0.0/bin/node index.js.

Quelle est la différence entre autorestart=true et autorestart=unexpected ?▼

'autorestart=true' relance inconditionnellement le processus dès qu'il prend fin, même avec un code de succès 0. 'autorestart=unexpected' ne le relance que si le processus se termine avec un code d'erreur non déclaré dans 'exitcodes' (par défaut 0 et 2).

Comment déclarer des variables d'environnement dans la configuration Supervisord ?▼

Utilisez la directive 'environment=' en séparant les paires clé-valeur par des virgules : environment=PORT="8080",APP_ENV="production". Les valeurs contenant des espaces ou des virgules doivent être encadrées de guillemets doubles.

Outils et utilitaires connexes

Tous les outils →
Référence Développeur HAProxy Config GeneratorDéveloppement

Générateur et validateur syntaxique de configurations HAProxy taillé pour la production.

Ouvrir l'outil→
Guide Développeur du Générateur de Helm Charts Kubernetes (Chart.yaml & values.yaml)Développement

Générez des fichiers standard Kubernetes Helm v3 Chart.yaml, values.yaml et modèles de déploiement avec Service, Ingress et limites de ressources.

Ouvrir l'outil→
Guide Développeur du Générateur de Dockerfile Multi-Étapes (Node, Go, Python, Rust)Développement

Générez des Dockerfiles multi-étapes sécurisés et ultra-légers pour Node.js, Golang, Python, Rust et Java avec utilisateur non-root et optimisation du cache BuildKit.

Ouvrir l'outil→
Référence Développeur Sql To KyselyDéveloppement

Manuel technique de référence et générateur de schémas pour convertir des définitions SQL DDL en interfaces TypeScript Kysely robustes pour PostgreSQL, MySQL et SQLite.

Ouvrir l'outil→
Guide du Développeur du Générateur d'Entités MikroORM TypeScript depuis SQL DDLDéveloppement

Convertissez les instructions SQL CREATE TABLE en classes d'entité MikroORM avec @Entity, @PrimaryKey, @Property, @Index et relations.

Ouvrir l'outil→
Guide Développeur : Générateur de Schémas Mongoose et Modèles TypeScript depuis JSONDéveloppement

Infère et génère des schémas MongoDB Mongoose, interfaces Document TypeScript, sous-documents imbriqués, horodatages et modèles exportables depuis du JSON.

Ouvrir l'outil→