Il s'agit du superviseur de commandes qui peut être exécuté dans le fournisseur d'hébergement gratuit OnWorks à l'aide de l'un de nos multiples postes de travail en ligne gratuits tels que Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS.
PROGRAMME:
Nom
superviseur - Superviseur Documentation
Supervisor est un système client/serveur qui permet à ses utilisateurs de surveiller et de contrôler un certain nombre
des processus sur des systèmes d'exploitation de type UNIX.
Il partage certains des mêmes objectifs que des programmes tels que launchd, daemontools et runit. contrairement à
certains de ces programmes, il n'est pas destiné à remplacer init comme "ID de processus
1". Au lieu de cela, il est destiné à être utilisé pour contrôler les processus liés à un projet ou un
client, et est destiné à démarrer comme n'importe quel autre programme au moment du démarrage.
RÉCIT DOCUMENTATION
Introduction
Informations clés
Supervisor est un système client/serveur qui permet à ses utilisateurs de contrôler un certain nombre de
processus sur des systèmes d'exploitation de type UNIX. Il a été inspiré par les éléments suivants :
Commodité
Il est souvent gênant d'avoir à écrire rc.d des scripts pour chaque processus
exemple. rc.d les scripts sont une excellente forme de processus au plus petit dénominateur commun
initialisation/démarrage automatique/gestion, mais ils peuvent être pénibles à écrire et à maintenir.
En outre, rc.d les scripts ne peuvent pas redémarrer automatiquement un processus bloqué et de nombreux
les programmes ne se redémarrent pas correctement en cas de plantage. Le superviseur démarre les processus
comme ses sous-processus, et peut être configuré pour les redémarrer automatiquement en cas de plantage.
Il peut également être automatiquement configuré pour démarrer des processus sur sa propre invocation.
Précision
Il est souvent difficile d'obtenir un statut up/down précis sur les processus sous UNIX. Fichiers pid
ment souvent. Supervisord démarre les processus en tant que sous-processus, il connaît donc toujours le vrai
statut up/down de ses enfants et peut être interrogé commodément pour ces données.
Délégation
Les utilisateurs qui ont besoin de contrôler l'état du processus n'ont souvent qu'à le faire. Ils ne veulent pas ou
besoin d'un accès shell complet à la machine sur laquelle les processus s'exécutent.
Les processus qui écoutent sur les ports TCP "bas" doivent souvent être démarrés et redémarrés en tant que
utilisateur root (un problème UNIX). C'est généralement le cas qu'il est parfaitement acceptable de permettre
des personnes "normales" pour arrêter ou redémarrer un tel processus, mais en leur fournissant un accès shell
est souvent peu pratique, et leur fournir un accès root ou sudo est souvent
impossible. Il est aussi (à juste titre) difficile de leur expliquer pourquoi ce problème existe.
Si Supervisord est démarré en tant que root, il est possible de permettre aux utilisateurs "normaux" de contrôler
de tels processus sans avoir besoin de leur expliquer les subtilités du problème.
Supervisorctl permet une forme très limitée d'accès à la machine, permettant essentiellement
aux utilisateurs de voir l'état du processus et de contrôler les sous-processus supervisés en émettant
Commandes "stop", "start" et "restart" à partir d'un simple shell ou d'une interface utilisateur Web.
Groupes de processus
Les processus doivent souvent être démarrés et arrêtés en groupe, parfois même en « priorité
ordre". Il est souvent difficile d'expliquer aux gens comment faire cela. Le superviseur permet
vous permet d'attribuer des priorités aux processus et permet à l'utilisateur d'émettre des commandes via le
le client superviseurctl comme "start all" et "restart all", qui les démarre dans le
ordre de priorité préassigné. De plus, les processus peuvent être regroupés en « processus
groupes" et un ensemble de processus logiquement liés peuvent être arrêtés et démarrés en tant qu'unité.
Comment ça marche
Simple
Supervisor est configuré via un simple fichier de configuration de style INI qui est facile à apprendre.
Il fournit de nombreuses options par processus qui vous facilitent la vie, comme l'échec du redémarrage
processus et rotation automatique des journaux.
Centralisée
Supervisor vous offre un emplacement unique pour démarrer, arrêter et surveiller vos processus.
Les processus peuvent être contrôlés individuellement ou en groupes. Vous pouvez configurer Supervisor pour
fournir une ligne de commande locale ou distante et une interface Web.
Efficace
Supervisor démarre ses sous-processus via fork/exec et les sous-processus ne sont pas démonisés. le
le système d'exploitation signale immédiatement au superviseur lorsqu'un processus se termine, contrairement à certains
les solutions qui reposent sur des fichiers PID gênants et des interrogations périodiques pour redémarrer ont échoué
procédés.
Extensible
Supervisor a un protocole de notification d'événement simple qui programme écrit dans n'importe quel
langage peut utiliser pour le surveiller, et une interface XML-RPC pour le contrôle. Il est également construit
avec des points d'extension pouvant être exploités par les développeurs Python.
Compatibilité
Supervisor fonctionne sur à peu près tout, à l'exception de Windows. Il est testé et
pris en charge sur Linux, Mac OS X, Solaris et FreeBSD. Il est entièrement écrit en Python,
donc l'installation ne nécessite pas de compilateur C.
Expérience
Bien que Supervisor soit très activement développé aujourd'hui, il ne s'agit pas d'un nouveau logiciel. Superviseur
existe depuis des années et est déjà utilisé sur de nombreux serveurs.
Superviseur Composants
superviseur
La partie serveur du superviseur est nommée superviseur. Il est chargé de démarrer
programmes enfants à sa propre invocation, réponse aux commandes des clients, redémarrage
sous-processus plantés ou quittés, journalisation de son sous-processus Stdout et stderr sortie, et
générer et gérer des "événements" correspondant à des points dans les durées de vie des sous-processus.
Le processus serveur utilise un fichier de configuration. Celui-ci est généralement situé dans
/etc/superviseur.conf. Ce fichier de configuration est un fichier de configuration de style "Windows-INI".
Il est important de garder ce fichier sécurisé via des autorisations de système de fichiers appropriées car il
peut contenir des noms d'utilisateur et des mots de passe non cryptés.
superviseur
L'élément client en ligne de commande du superviseur est nommé superviseur. Il fournit un
interface de type shell aux fonctionnalités fournies par superviseur. Vous y trouverez des superviseur, un
l'utilisateur peut se connecter à différents superviseur processus, obtenir le statut sur les sous-processus
contrôlé par, arrêter et démarrer les sous-processus de, et obtenir des listes de processus en cours d'un
superviseur.
Le client en ligne de commande communique avec le serveur via un socket de domaine UNIX ou un réseau Internet
(TCP). Le serveur peut affirmer que l'utilisateur d'un client doit présenter
informations d'authentification avant qu'il ne lui permette d'exécuter des commandes. Le client
processus utilise généralement le même fichier de configuration que le serveur mais n'importe quelle configuration
fichier avec un [superviseur] section dans cela fonctionnera.
Web Server
Une interface utilisateur Web (épurée) avec des fonctionnalités comparables à superviseur peut être
accessible via un navigateur si vous démarrez superviseur contre une prise internet. Visiter le
URL du serveur (par exemple http://localhost: 9001 /) pour afficher et contrôler l'état du processus via le
interface web après avoir activé le fichier de configuration [inet_http_serveur] .
Interface XML-RPC
Le même serveur HTTP qui sert l'interface utilisateur Web sert une interface XML-RPC qui peut être
utilisé pour interroger et contrôler le superviseur et les programmes qu'il exécute. Voir xml_rpc.
Plateforme Exigences
Supervisor a été testé et est connu pour fonctionner sous Linux (Ubuntu 9.10), Mac OS X
(10.4/10.5/10.6), et Solaris (10 pour Intel) et FreeBSD 6.1. Cela fonctionnera probablement bien sur
la plupart des systèmes UNIX.
Le superviseur pas fonctionner du tout sous n'importe quelle version de Windows.
Supervisor est connu pour fonctionner avec Python 2.4 ou version ultérieure, mais ne fonctionnera sous aucune version
de Python 3.
Fonctionnement Superviseur
Cette section fait référence à un BINDER en expliquant comment exécuter le superviseur et
superviseur commandes. Il s'agit du répertoire "bindir" de votre installation Python
été configuré avec. Par exemple, pour une installation de Python installée via
. / Configure --prefix=/usr/local/py; Fabriquer; a prendre une installer, BINDER serait /usr/local/py/bin.
Les interpréteurs Python sur différentes plates-formes utilisent un BINDER. Regardez la sortie de
configuration.py installer si vous ne pouvez pas savoir où se trouve le vôtre.
L'ajout de a Programme
Avant superviseur fera quelque chose d'utile pour vous, vous devrez ajouter au moins un
Programme section à sa configuration. Les Programme section définira un programme qui est
exécuté et géré lorsque vous appelez le superviseur commander. Pour ajouter un programme, vous devrez
modifier le superviseur.conf fichier.
L'un des programmes les plus simples à exécuter est UNIX cat programme. UNE Programme
qui va courir cat lorsque le superviseur processus démarre est illustré ci-dessous.
[programme:toto]
commande =/bin/chat
Cette strophe peut être coupée et collée dans le superviseur.conf déposer. C'est le plus simple
configuration possible du programme, car il ne nomme qu'une commande. Paramétrage du programme
sections ont de nombreuses autres options de configuration qui ne sont pas affichées ici. Voir
programx_section pour plus d'informations.
Fonctionnement superviseur
Pour commencer superviseur, courir $BINDIR/superviseur. Le processus résultant va démoniser
lui-même et se détacher du terminal. Il tient un journal des opérations à $CWD/superviseur.log by
défaut.
Vous pouvez commencer le superviseur exécutable au premier plan en passant le -n drapeau sur son
ligne de commande. Ceci est utile pour déboguer les problèmes de démarrage.
AVERTISSEMENT:
Quand superviseur démarre, il recherchera son fichier de configuration par défaut
restaurants comme le actuel de travail annuaire. Si vous êtes soucieux de la sécurité, vous
voudra probablement spécifier un argument "-c" après le superviseur commande spécifiant
un chemin absolu vers un fichier de configuration pour s'assurer que quelqu'un ne vous trompe pas
exécuter le superviseur à partir d'un répertoire qui contient un escroc superviseur.conf fichier.
Un avertissement est émis lorsque le superviseur est démarré en tant que root sans ce -c argument.
Pour changer l'ensemble des programmes contrôlés par superviseur, modifiez le superviseur.conf filet
et tuer -HUP ou autrement redémarrer le superviseur traiter. Ce fichier a plusieurs exemple
définitions de programmes.
Le manuel de formation superviseur La commande accepte un certain nombre d'options de ligne de commande. Chacune de ces commandes
Les options de ligne remplacent toute valeur équivalente dans le fichier de configuration.
superviseur Ligne de commande Options
-c DOSSIER, --configuration=DOSSIER
Le chemin vers un superviseur fichier de configuration.
-n, --nodémon
Courir superviseur au premier plan.
-h, --Aidez-moi
Afficher superviseur aide à la commande.
-u UTILISATEUR, --utilisateur=UTILISATEUR
Nom d'utilisateur UNIX ou identifiant d'utilisateur numérique. Si superviseur est démarré en tant qu'utilisateur root,
setuid à cet utilisateur dès que possible lors du démarrage.
-m OCTAL, --umask=OCTAL
Nombre octal (par exemple 022) représentant le umask qui devrait être utilisé par superviseur
après qu'il démarre.
-d PATH, --répertoire=PATH
Lorsque Supervisord est exécuté en tant que démon, dirigez-vous vers ce répertoire avant de procéder au démon.
-l DOSSIER, --fichier journal=DOSSIER
Chemin du nom de fichier à utiliser comme journal d'activité supervisé.
-y OCTETS, --logfile_maxbytes=OCTETS
Taille maximale du fichier journal des activités supervisées avant qu'une rotation ne se produise. La valeur
est multiplié par un suffixe, par exemple "1" est un octet, "1 Mo" est 1 mégaoctet, "1 Go" est 1
gigaoctet.
-y NUM, --logfile_backups=NUM
Nombre de copies de sauvegarde du journal des activités supervisées à conserver. Chaque
le fichier journal sera de taille fichier journal_maxoctets.
-e NIVEAU, --loglevel=NIVEAU
Le niveau de journalisation auquel le superviseur doit écrire dans le journal d'activité. Valide
les niveaux sont tracer, déboguer, info, prévenir, erreuret critique.
-j DOSSIER, --pidfile=DOSSIER
Le nom de fichier sur lequel superviseurd doit écrire son fichier pid.
-i STRING, --identifiant=STRING
Identificateur de chaîne arbitraire exposé par diverses interfaces utilisateur client pour cette instance de
superviseur.
-q PATH, --childlogdir=PATH
Un chemin vers un répertoire (il doit déjà exister) où le superviseur écrira son AUTO
-journaux de processus enfants en mode.
-k, --pas de nettoyage
Prévenir superviseur d'effectuer le nettoyage (retrait de l'ancien AUTO fichiers journaux de traitement)
au démarrage.
-a NUM, --minfds=NUM
Le nombre minimum de descripteurs de fichiers qui doivent être disponibles pour le superviseur
processus avant qu'il ne démarre avec succès.
-t, --strip_ansi
Supprimez les séquences d'échappement ANSI de tous les processus de journal enfants.
-v, --version
Imprimez le numéro de version supervisé sur stdout et quittez.
--profile_options=LISTE
Liste d'options séparées par des virgules pour le profilage. Causes superviseur courir sous un
profileur, et les résultats de sortie basés sur les options, qui est une liste séparée par des virgules
du suivant: accumulé, en cours, appelants. Par exemple cumulatif,appelants.
--minprocs=NUM
Le nombre minimum d'emplacements de processus OS qui doivent être disponibles pour le superviseur
processus avant qu'il ne démarre avec succès.
superviseur Ligne de commande Options
-c, --configuration
Chemin du fichier de configuration (par défaut /etc/supervisord.conf)
-h, --Aidez-moi
Imprimer le message d'utilisation et quitter
-i, --interactif
Démarrer un shell interactif après avoir exécuté des commandes
-s,--URLduserveur URL
URL sur laquelle écoute le serveur supervisé (par défaut "http://localhost: 9001").
-u, --Nom d'utilisateur
Nom d'utilisateur à utiliser pour l'authentification avec le serveur
-p, --le mot de passe
Mot de passe à utiliser pour l'authentification avec le serveur
-r, --historique-fichier
Conserver un historique readline (si readline est disponible)
action [arguments]
Les actions sont des commandes telles que "queue" ou "arrêt". Si -i est spécifié ou aucune action n'est spécifiée
en ligne de commande, un "shell" interprétant les actions saisies de manière interactive est lancé. Utilisation
l'action "aide" pour connaître les actions disponibles.
Fonctionnement superviseur
Pour commencer superviseur, courir $BINDIR/superviseurctl. Une coquille sera présentée qui
vous permettent de contrôler les processus actuellement gérés par superviseur. Tapez "aide"
à l'invite pour obtenir des informations sur les commandes prises en charge.
Le manuel de formation superviseur l'exécutable peut être invoqué avec des commandes « uniques » lorsqu'il est invoqué avec
arguments à partir d'une ligne de commande. Un exemple: superviseur Arrêtez tous. Si les arguments sont
présent sur la ligne de commande, il empêchera l'invocation du shell interactif.
Au lieu de cela, la commande sera exécutée et superviseur va sortir.
If superviseur est invoqué en mode interactif contre un superviseur cela requiert
authentification, il vous sera demandé des informations d'authentification.
Signalétique
Le manuel de formation superviseur programme peut recevoir des signaux qui l'obligent à effectuer certaines actions
pendant qu'il tourne.
Vous pouvez envoyer n'importe lequel de ces signaux au single superviseur identifiant de processus Cet identifiant de processus
se trouve dans le fichier représenté par le fichier pid paramètre dans la [superviseur]
du fichier de configuration (par défaut c'est $CWD/superviseur.pid).
Signal Gestionnaires
SIGTERME
superviseur et tous ses sous-processus s'arrêteront. Cela peut prendre plusieurs secondes.
SIGINT
superviseur et tous ses sous-processus s'arrêteront. Cela peut prendre plusieurs secondes.
TELLEMENT DE
superviseur et tous ses sous-processus s'arrêteront. Cela peut prendre plusieurs secondes.
VUE D'ENSEMBLE
superviseur arrêtera tous les processus, rechargera la configuration à partir de la première config
fichier qu'il trouve et redémarrez tous les processus.
SIGUSR2
superviseur fermera et rouvrira le journal d'activité principal et tous les fichiers journaux enfants.
Runtime Sécurité
Les développeurs ont fait de leur mieux pour garantir que l'utilisation d'un superviseur processus s'exécutant en tant que
root ne peut pas conduire à une élévation de privilèges involontaire. Mais caveat videur. Le superviseur est
pas aussi paranoïaque que quelque chose comme les démontools de DJ Bernstein, dans la mesure où superviseur
autorise des spécifications de chemin arbitraires dans son fichier de configuration auquel les données peuvent être
écrit. Autoriser des sélections de chemin arbitraires peut créer des vulnérabilités à partir du lien symbolique
attaques. Soyez prudent lorsque vous spécifiez des chemins dans votre configuration. Assurez-vous que le
superviseur le fichier de configuration ne peut pas être lu ou écrit par des utilisateurs non privilégiés et
que tous les fichiers installés par le package superviseur ont une protection d'autorisation de fichier "saine"
Les paramètres. De plus, assurez-vous que votre PYTHONPATH est sain d'esprit et que tous les standards Python
les fichiers de bibliothèque ont des protections d'autorisation de fichier adéquates.
Fonctionnement superviseur automatiquement on Commencez
Si vous utilisez une version packagée de la distribution de Supervisor, elle devrait déjà être
intégré à l'infrastructure de gestion des services de votre distribution.
Il existe des scripts fournis par les utilisateurs pour divers systèmes d'exploitation à l'adresse :
https://github.com/Supervisor/initscripts
Il y a quelques réponses sur Serverfault au cas où vous seriez bloqué : Comment la à automatiquement Commencer
superviseur on Linux (Ubuntu)
Configuration Fichier
Le fichier de configuration Supervisor est classiquement nommé superviseur.conf. Il est utilisé par
tous les deux superviseur et superviseur. Si l'une des applications est démarrée sans le -c
option (l'option qui est utilisée pour indiquer à l'application le nom du fichier de configuration
explicitement), l'application recherchera un fichier nommé superviseur.conf au sein du
emplacements suivants, dans l'ordre spécifié. Il utilisera le premier fichier qu'il trouvera.
1. $CWD/superviseur.conf
2. $CWD/etc/superviseur.conf
3. /etc/superviseur.conf
4. ../etc/superviseur.conf (Par rapport à l'exécutable)
5. ../superviseur.conf (Par rapport à l'exécutable)
NOTE:
Certaines distributions ont empaqueté Supervisor avec leurs propres personnalisations. Ces
les versions modifiées de Supervisor peuvent charger le fichier de configuration à partir d'autres emplacements
que celles décrites ici. Notamment, des packages Ubuntu ont été trouvés qui utilisent
/etc/supervisor/supervisord.conf.
Fichier Format
superviseur.conf est un fichier de style Windows-INI (Python ConfigParser). Il a des sections (chacune
désigné par un [entête]) et des paires clé/valeur dans les sections. Les sections et leurs
les valeurs admissibles sont décrites ci-dessous.
Environnement Variables
Les variables d'environnement qui sont présentes dans l'environnement au moment où superviseur is
start peut être utilisé dans le fichier de configuration à l'aide de la syntaxe d'expression de chaîne Python
%(ENV_X)s:
[programme:exemple]
commande=/usr/bin/exemple --loglevel=%(ENV_LOGLEVEL)s
Dans l'exemple ci-dessus, l'expression %(ENV_LOGLEVEL)s serait étendu à la valeur de
la variable d'environnement NIVEAU DE CONNEXION.
NOTE:
Dans Supervisor 3.2 et versions ultérieures, %(ENV_X)s les expressions sont prises en charge dans toutes les options. Dans
versions antérieures, certaines options les prennent en charge, mais pas la plupart. Voir la documentation pour
chaque option ci-dessous.
[unix_http_serveur] Blog Paramètres
Le manuel de formation superviseur.conf le fichier contient une section nommée [unix_http_serveur] sous lequel
les paramètres de configuration d'un serveur HTTP qui écoute sur un socket de domaine UNIX doivent être
inséré. Si le fichier de configuration n'a pas [unix_http_serveur] section, un domaine UNIX
Le serveur HTTP socket ne sera pas démarré. Les valeurs de configuration autorisées sont les
suit.
[unix_http_serveur] Blog Nos valeurs
filet
Un chemin vers un socket de domaine UNIX (par exemple /tmp/supervisord.sock) sur quel superviseur
écouter les requêtes HTTP/XML-RPC. superviseur utilise XML-RPC pour communiquer avec
superviseur sur ce port. Cette option peut inclure la valeur %(ici)s, qui s'étend
au répertoire dans lequel le superviseur fichier de configuration a été trouvé.
Réglage par défaut: Aucun.
Requis: Non
Introduit3.0
chmod
Remplacez les bits de mode d'autorisation UNIX du socket de domaine UNIX par cette valeur à
Commencez.
Réglage par défaut: 0700
Requis: Non
Introduit3.0
chown
Remplacez l'utilisateur et le groupe du fichier socket par cette valeur. Peut être un nom d'utilisateur UNIX
(par exemple chrism) ou un nom d'utilisateur et un groupe UNIX séparés par deux points (par exemple chrême:roue).
Réglage par défaut: Utilisez le nom d'utilisateur et le groupe de l'utilisateur qui démarre superviseur.
Requis: Non
Introduit3.0
Nom d'utilisateur
Le nom d'utilisateur requis pour l'authentification sur ce serveur HTTP.
Réglage par défaut: Aucun nom d'utilisateur requis.
Requis: Non
Introduit3.0
Le mot de passe requis pour l'authentification sur ce serveur HTTP. Cela peut être un texte clair
mot de passe, ou peut être spécifié en tant que hachage SHA-1 s'il est préfixé par la chaîne {SHA}. For
Par exemple, {SHA}82ab876d1387bfafe46cc1c8a2ef074eae50cb1d est la version stockée par SHA du
mot de passe "lemot de passe".
Notez que le mot de passe haché doit être au format hexadécimal.
Réglage par défaut: Aucun mot de passe requis.
Requis: Non
Introduit3.0
[unix_http_serveur] Blog Exemple
[unix_http_serveur]
fichier = /tmp/superviseur.sock
chmod = 0777
chown=personne:nogroup
nom d'utilisateur = utilisateur
mot de passe = 123
[inet_http_serveur] Blog Paramètres
Le manuel de formation superviseur.conf le fichier contient une section nommée [inet_http_serveur] sous lequel
les paramètres de configuration d'un serveur HTTP qui écoute sur un socket TCP (internet) doivent
être inséré. Si le fichier de configuration n'a pas [inet_http_serveur] section, un inet HTTP
le serveur ne sera pas démarré. Les valeurs de configuration autorisées sont les suivantes.
[inet_http_serveur] Blog Nos valeurs
port
Un hôte TCP:valeur de port ou (par exemple 127.0.0.1:9001) sur lequel le superviseur écoutera
Requêtes HTTP/XML-RPC. superviseur utilisera XML-RPC pour communiquer avec superviseur
sur ce port. Pour écouter sur toutes les interfaces de la machine, utilisez : 9001 or *:9001.
Réglage par défaut: Aucun défaut.
Requis: Oui.
Introduit3.0
Nom d'utilisateur
Le nom d'utilisateur requis pour l'authentification sur ce serveur HTTP.
Réglage par défaut: Aucun nom d'utilisateur requis.
Requis: Non
Introduit3.0
Le mot de passe requis pour l'authentification sur ce serveur HTTP. Cela peut être un texte clair
mot de passe, ou peut être spécifié en tant que hachage SHA-1 s'il est préfixé par la chaîne {SHA}. For
Par exemple, {SHA}82ab876d1387bfafe46cc1c8a2ef074eae50cb1d est la version stockée par SHA du
mot de passe "lemot de passe".
Notez que le mot de passe haché doit être au format hexadécimal.
Réglage par défaut: Aucun mot de passe requis.
Requis: Non
Introduit3.0
[inet_http_serveur] Blog Exemple
[inet_http_serveur]
port = 127.0.0.1:9001
nom d'utilisateur = utilisateur
mot de passe = 123
[superviseur] Blog Paramètres
Le manuel de formation superviseur.conf le fichier contient une section nommée [superviseur] dans quels paramètres globaux
au niveau de la superviseur processus doit être inséré. Ce sont les suivants.
[superviseur] Blog Nos valeurs
fichier journal
Le chemin d'accès au journal d'activité du processus supervisé. Cette option peut inclure le
Plus-value %(ici)s, qui se développe jusqu'au répertoire dans lequel la configuration supervisée
fichier a été trouvé.
Réglage par défaut: $CWD/superviseur.log
Requis: Non
Introduit3.0
fichier journal_maxoctets
Le nombre maximal d'octets pouvant être consommés par le fichier journal d'activité avant qu'il ne soit
tourné (des multiplicateurs de suffixe tels que "KB", "MB" et "GB" peuvent être utilisés dans la valeur). Régler
cette valeur à 0 pour indiquer une taille de journal illimitée.
Réglage par défaut: 50MB
Requis: Non
Introduit3.0
fichier_journal_sauvegardes
Le nombre de sauvegardes à conserver résultant de la rotation des fichiers journaux d'activité. Si défini
à 0, aucune sauvegarde ne sera conservée.
Réglage par défaut10
Requis: Non
Introduit3.0
loglevel
Le niveau de journalisation, dictant ce qui est écrit dans le journal d'activité supervisé. Un des
critique, erreur, prévenir, info, déboguer, tracer, ou bêtises. Notez qu'au niveau du journal déboguer,
le fichier journal supervisé enregistrera la sortie stderr/stdout de ses processus enfants
et des informations étendues sur les changements d'état du processus, ce qui est utile pour déboguer un
processus qui ne démarre pas correctement. Voir aussi : activity_log_levels.
Réglage par défaut: Info
Requis: Non
Introduit3.0
fichier pid
L'emplacement dans lequel superviseurd conserve son fichier pid. Cette option peut inclure le
Plus-value %(ici)s, qui se développe jusqu'au répertoire dans lequel la configuration supervisée
fichier a été trouvé.
Réglage par défaut: $CWD/superviseur.pid
Requis: Non
Introduit3.0
umask
L'umask du processus supervisé.
Réglage par défaut: 022
Requis: Non
Introduit3.0
nodémon
Si vrai, superviseurd commencera au premier plan au lieu de démoniser.
Réglage par défaut: faux
Requis: Non
Introduit3.0
esprit
Le nombre minimum de descripteurs de fichiers qui doivent être disponibles avant que le superviseur ne
démarrer avec succès. Un appel à setrlimit sera effectué pour tenter d'augmenter le soft et
limites strictes du processus supervisé à satisfaire esprit. La limite stricte ne peut être que
déclenché sisupervisord est exécuté en tant que root. Supervisé utilise généreusement les descripteurs de fichiers, et
entrera en mode d'échec lorsqu'il ne pourra pas être obtenu à partir du système d'exploitation, il est donc utile d'être
capable de spécifier une valeur minimale pour s'assurer qu'il n'en manque pas pendant l'exécution.
Cette option est particulièrement utile sur Solaris, qui a une faible limite fd par processus par
défaut.
Réglage par défaut1024
Requis: Non
Introduit3.0
minprocs
Le nombre minimum de descripteurs de processus qui doivent être disponibles avant le superviseur
démarrera avec succès. Un appel à setrlimit sera effectué pour tenter d'augmenter le soft
et les limites strictes du processus supervisé pour satisfaire minprocs. La limite stricte peut
être déclenché uniquement si superviseurd est exécuté en tant que root. Supervisé entrera en mode échec
lorsque le système d'exploitation manque de descripteurs de processus, il est donc utile de s'assurer que suffisamment
les descripteurs de processus sont disponibles sur superviseur Commencez.
Réglage par défaut200
Requis: Non
Introduit3.0
pas de nettoyage
Empêcher le superviseur d'effacer tout AUTO fichiers journaux enfants au démarrage.
Utile pour le débogage.
Réglage par défaut: faux
Requis: Non
Introduit3.0
rép du journal des enfants
Le répertoire utilisé pour AUTO fichiers journaux enfants. Cette option peut inclure la valeur
%(ici)s, qui se développe jusqu'au répertoire dans lequel le superviseur fichier de configuration
a été trouvé.
Réglage par défaut: valeur de Python fichier_temp.get_tempdir()
Requis: Non
Introduit3.0
utilisateur
Instruire superviseur pour basculer les utilisateurs vers ce compte utilisateur UNIX avant de faire
traitement significatif. L'utilisateur ne peut être commuté que si superviseur est démarré en tant que
utilisateur root. Si superviseur ne peut pas changer d'utilisateur, il continuera mais écrira un
message de journal au critique niveau en disant qu'il ne peut pas supprimer les privilèges.
Réglage par défaut: ne pas changer d'utilisateur
Requis: Non
Introduit3.0
annuaire
Quand superviseur démonise, basculez vers ce répertoire. Cette option peut inclure le
Plus-value %(ici)s, qui se développe jusqu'au répertoire dans lequel le superviseur paramétrage
fichier a été trouvé.
Réglage par défaut: ne pas cd
Requis: Non
Introduit3.0
strip_ansi
Supprimez toutes les séquences d'échappement ANSI des fichiers journaux enfants.
Réglage par défaut: faux
Requis: Non
Introduit3.0
convivial
Une liste de paires clé/valeur sous la forme KEY="val", KEY2="val2" qui sera placé dans le
superviseur process' environnement (et par conséquent dans tous ses processus fils'
environnements). Cette option peut inclure la valeur %(ici)s, qui s'étend au
répertoire dans lequel le fichier de configuration supervisé a été trouvé. Valeurs contenant
les caractères non alphanumériques doivent être entre guillemets (par ex. KEY="val:123",KEY2="val,456").
Sinon, la citation des valeurs est facultative mais recommandée. Pour échapper à pour cent
caractères, utilisez simplement deux. (par exemple URI="/premier%%20nom") Note que les sous-processus
hériter des variables d'environnement du shell utilisé pour démarrer superviseur sauf pour le
ceux annulés ici et dans le programme convivial option. Voir
environnement_sous-processus.
Réglage par défaut: aucune valeur
Requis: Non
Introduit3.0
identifiant
La chaîne d'identifiant de ce processus superviseur, utilisée par l'interface RPC.
Réglage par défaut: superviseur
Requis: Non
Introduit3.0
[superviseur] Blog Exemple
[superviseur]
fichier journal = /tmp/supervisord.log
logfile_maxbytes = 50 Mo
fichier_journal_backups=10
niveau de journalisation = info
pidfile = /tmp/supervisord.pid
nodemon = faux
minfd = 1024
minprocs = 200
masque = 022
utilisateur = chrême
identifiant = superviseur
répertoire = / Tmp
nocleanup = vrai
enfantlogdir = / Tmp
strip_ansi = faux
environnement = KEY1="valeur1",KEY2="valeur2"
[superviseur] Blog Paramètres
Le fichier de configuration peut contenir des paramètres pour le superviseur shell interactif
programme. Ces options sont répertoriées ci-dessous.
[superviseur] Blog Nos valeurs
URL du serveur
L'URL qui doit être utilisée pour accéder au serveur supervisé, par exemple
http://localhost: 9001. Pour les sockets de domaine UNIX, utilisez
unix:///absolute/chemin/vers/fichier.sock.
Réglage par défaut: http://localhost: 9001
Requis: Non
Introduit3.0
Nom d'utilisateur
Le nom d'utilisateur à transmettre au serveur supervisé pour une utilisation dans l'authentification. Ceci devrait
être le même que Nom d'utilisateur depuis la configuration du serveur supervisé pour le port ou UNIX
socket de domaine auquel vous essayez d'accéder.
Réglage par défaut: pas de nom d'utilisateur
Requis: Non
Introduit3.0
Le mot de passe à transmettre au serveur supervisé pour l'authentification. Ceci devrait
être la version en clair de à partir de la configuration du serveur supervisé pour le
port ou socket de domaine UNIX auquel vous essayez d'accéder. Cette valeur ne peut pas être transmise comme
un hachage SHA. Contrairement aux autres mots de passe spécifiés dans ce fichier, il doit être fourni dans
effacer le texte.
Réglage par défaut: Pas de mot de passe
Requis: Non
Introduit3.0
prompt
Chaîne utilisée comme invite de superviseurctl.
Réglage par défaut: superviseur
Requis: Non
Introduit3.0
fichier_historique
Un chemin à utiliser comme readline fichier historique persistant. Si vous activez cette fonctionnalité en
en choisissant un chemin, vos commandes superviseurctl seront conservées dans le fichier, et vous pourrez utiliser
readline (par exemple, flèche vers le haut) pour appeler les commandes que vous avez effectuées dans votre dernier superviseurctl
session.
Réglage par défaut: Pas de fichier
Requis: Non
Introduit: 3.0a5
[superviseur] Blog Exemple
[superviseur]
URL du serveur = unix:///tmp/supervisor.sock
nom d'utilisateur = chris
mot de passe = 123
invite = monsuperviseur
[programme : x] Blog Paramètres
Le fichier de configuration doit contenir un ou plusieurs Programme sections afin d'être supervisé
pour savoir quels programmes il doit démarrer et contrôler. La valeur d'en-tête est une valeur composite.
Il s'agit du mot "programme", suivi directement de deux points, puis du nom du programme. Un en-tête
valeur de [programme:toto] décrit un programme avec le nom de "foo". Le nom est utilisé
dans les applications clientes qui contrôlent les processus créés à la suite de cette
configuration. C'est une erreur de créer un Programme section qui n'a pas de nom. Les
le nom ne doit pas inclure de caractère deux-points ou de crochet. La valeur du nom est
utilisé comme valeur pour le %(nom_programme)s expansion d'expression de chaîne dans d'autres valeurs
où spécifié.
NOTE:
A [programme : x] La section représente en fait un « groupe de processus homogène » pour le superviseur
(à partir de 3.0). Les membres du groupe sont définis par la combinaison des nombres
et nom du processus paramètres dans la configuration. Par défaut, si numprocs et
process_name restent inchangés par rapport à leurs valeurs par défaut, le groupe représenté par
[programme : x] sera nommé x et aura un seul processus nommé x dedans. Cette
fournit un minimum de rétrocompatibilité avec les anciennes versions de superviseur, ce qui
ne pas traiter les sections de programme comme des définitions de groupes de processus homogènes.
Mais par exemple, si vous avez un [programme:toto] partie avec un nombres de 3 et un
nom du processus expression de %(nom_programme)s_%(numéro_processus)02d, le groupe "foo"
contiennent trois processus, nommés foo_00, foo_01et foo_02. Cela permet de
démarrer un certain nombre de processus très similaires en utilisant un seul [programme : x] section. Tous
les noms des fichiers journaux, toutes les chaînes d'environnement et la commande des programmes peuvent également contenir
expressions de chaîne Python similaires, pour passer des paramètres légèrement différents à chacun
processus.
[programme : x] Blog Nos valeurs
commander
La commande qui sera exécutée au démarrage de ce programme. La commande peut être soit
absolu (par exemple /chemin/vers/nom_programme) ou un parent (par exemple nom du programme). Si c'est
parent, l'environnement du surveillant $ CHEMIN sera recherché pour l'exécutable.
Les programmes peuvent accepter des arguments, par exemple /chemin/vers/programme foo Bar. La ligne de commande peut utiliser
guillemets doubles pour regrouper les arguments contenant des espaces à transmettre au programme, par exemple
/chemin/vers/programme/nom -p "toto bar". Notez que la valeur de commander peut inclure Python
expressions de chaîne, par exemple /chemin/vers/nom_programme --port=80%(num_processus)02d pourrait s'étendre
à /chemin/vers/nom_programme --port=8000 à l'exécution. Les expressions de chaîne sont évaluées
contre un dictionnaire contenant les clés nom de groupe, nom_noeud_hôte, num_processus,
nom du programme, here. (le répertoire du fichier de configuration supervisé), et tous
les variables d'environnement de superviseur préfixées par ENV_. Les programmes contrôlés devraient
ne sont pas eux-mêmes des démons, car Supervisord suppose qu'il est responsable de la démonisation de ses
sous-processus (voir nondaemonizing_of_subprocesses).
Réglage par défaut: Aucun défaut.
Requis: Oui.
Introduit3.0
nom du processus
Une expression de chaîne Python qui est utilisée pour composer le nom du processus superviseur pour ce
traiter. Vous n'avez généralement pas à vous soucier de la configuration à moins que vous ne modifiiez
nombres. L'expression de chaîne est évaluée par rapport à un dictionnaire qui inclut
nom de groupe, nom_noeud_hôte, num_processus, nom du programmeet here. (l'annuaire du
fichier de configuration supervisé).
Réglage par défaut: %(nom_programme)s
Requis: Non
Introduit3.0
nombres
Supervisor démarrera autant d'instances de ce programme que nommé par numprocs. Noter
que si numprocs > 1, le nom du processus l'expression doit inclure %(process_num)s (ou tout
autre expression de chaîne Python valide qui inclut num_processus) à l'intérieur.
Réglage par défaut1
Requis: Non
Introduit3.0
numprocs_start
Un décalage entier utilisé pour calculer le nombre auquel nombres départs.
Réglage par défaut0
Requis: Non
Introduit3.0
priorité
La priorité relative du programme dans l'ordre de démarrage et d'arrêt. Inférieur
les priorités indiquent les programmes qui démarrent en premier et s'arrêtent en dernier au démarrage et quand
Les commandes agrégées sont utilisées dans divers clients (par exemple, "tout démarrer"/"tout arrêter"). Plus haut
les priorités indiquent les programmes qui démarrent en dernier et s'arrêtent en premier.
Réglage par défaut999
Requis: Non
Introduit3.0
Autostart
Si vrai, ce programme démarrera automatiquement au démarrage de Supervisord.
Réglage par défaut: vrai
Requis: Non
Introduit3.0
démarre les secondes
Le nombre total de secondes dont le programme a besoin pour rester en cours d'exécution après un démarrage pour
considérer le démarrage comme réussi (déplacer le processus du DÉPART état à la
RUNNING Etat). Mis à 0 pour indiquer que le programme n'a pas besoin de rester en cours d'exécution pendant
quantité de temps particulière.
NOTE:
Même si un processus se termine avec un code de sortie « attendu » (voir codes de sortie), le début
sera toujours considéré comme un échec si le processus se termine plus rapidement que démarre les secondes.
Réglage par défaut1
Requis: Non
Introduit3.0
tentatives de démarrage
Le nombre de tentatives d'échec en série qui superviseur permettra en essayant de
démarrer le programme avant d'abandonner et de mettre le processus dans un MORTEL Etat. Voir
process_states pour l'explication du MORTEL Etat.
Réglage par défaut3
Requis: Non
Introduit3.0
redémarrage automatique
Spécifie si superviseur devrait redémarrer automatiquement un processus s'il se termine lorsqu'il est
dans le RUNNING Etat. Peut être l'un des non, inattendu, ou oui. Si non, le processus
ne sera pas redémarré automatiquement. Si inattendu, le processus sera redémarré lorsque le
le programme se termine avec un code de sortie qui n'est pas l'un des codes de sortie associés à ce
configuration du processus (voir codes de sortie). Si oui, le processus sera inconditionnellement
redémarré à sa sortie, sans tenir compte de son code de sortie.
NOTE:
redémarrage automatique contrôle si superviseur redémarrera automatiquement un programme s'il se termine
après avoir démarré avec succès (le processus est dans le RUNNING Etat).
superviseur a un mécanisme de redémarrage différent pour le démarrage du processus
(le processus est dans le DÉPART Etat). Les nouvelles tentatives lors du démarrage du processus sont
controlé par démarre les secondes et tentatives de démarrage.
Réglage par défaut: inattendu
Requis: Non
Introduit3.0
codes de sortie
La liste des codes de sortie « attendus » pour ce programme utilisé avec redémarrage automatique. Si l'
redémarrage automatique paramètre est défini sur inattendu, et le processus se termine autrement que
à la suite d'une demande d'arrêt du superviseur, superviseur redémarrera le processus s'il
sort avec un code de sortie qui n'est pas défini dans cette liste.
Réglage par défaut0,2
Requis: Non
Introduit3.0
stop
Le signal utilisé pour tuer le programme lorsqu'un arrêt est demandé. Cela peut être n'importe quel TERME,
HUP, INT, QUIT, KILL, USR1 ou USR2.
Réglage par défaut: TERME
Requis: Non
Introduit3.0
secondes d'attente
Le nombre de secondes à attendre pour que le système d'exploitation renvoie un SIGCHILD à superviseur après le
programme a reçu un signal d'arrêt. Si ce nombre de secondes s'écoule avant
superviseur reçoit un SIGCHILD du processus, superviseur tentera de le tuer
avec un SIGKILL final.
Réglage par défaut10
Requis: Non
Introduit3.0
groupe d'arrêt
Si vrai, l'indicateur oblige le superviseur à envoyer le signal d'arrêt à l'ensemble du groupe de processus
et implique groupe killas est vrai. Ceci est utile pour les programmes, tels que Flask en débogage
mode, qui ne propagent pas les signaux d'arrêt à leurs enfants, les laissant orphelins.
Réglage par défaut: faux
Requis: Non
Introduit: 3.0b1
groupe killas
Si vrai, lorsque vous recourez à envoyer SIGKILL au programme pour le terminer, envoyez-le à son
l'ensemble du groupe de processus à la place, en prenant également soin de ses enfants, utile par exemple avec
programmes Python utilisant multitraitement.
Réglage par défaut: faux
Requis: Non
Introduit: 3.0a11
utilisateur
Instruire superviseur d'utiliser ce compte utilisateur UNIX comme compte qui exécute le
programme. L'utilisateur ne peut être commuté que si superviseur est exécuté en tant qu'utilisateur root. Si
superviseur ne peut pas basculer vers l'utilisateur spécifié, le programme ne sera pas démarré.
NOTE:
L'utilisateur sera modifié en utilisant tranquille seul. Cela ne démarre pas un shell de connexion et
ne modifie pas les variables d'environnement comme UTILISATEUR or ACCUEIL. Voir
subprocess_environment pour plus de détails.
Réglage par défaut: Ne changez pas d'utilisateur
Requis: Non
Introduit3.0
redirect_stderr
Si vrai, renvoie la sortie stderr du processus à superviseur sur son stdout
descripteur de fichier (en termes de shell UNIX, cela équivaut à exécuter /le programme
2> et 1).
NOTE:
Ne pas fixer redirect_stderr = vrai dans un [écouteur d'événement : x] section. Auditeurs d'événements
utilisé Stdout et Stdin communiquer avec superviseur. Si stderr est redirigé,
sortie de stderr interférera avec le protocole d'écoute d'événement.
Réglage par défaut: faux
Requis: Non
Introduit: 3.0, remplace les 2.0 log_stdout et log_stderr
fichier_journal_stdout
Mettez la sortie stdout du processus dans ce fichier (et si redirect_stderr est vrai, placez également
sortie stderr dans ce fichier). Si fichier_journal_stdout est désactivé ou réglé sur AUTO, superviseur
choisira automatiquement un emplacement de fichier. S'il est défini sur NONE, sera supervisé
créer aucun fichier journal. AUTO les fichiers journaux et leurs sauvegardes seront supprimés lorsque superviseur
redémarre. Les fichier_journal_stdout value peut contenir des expressions de chaîne Python qui
évalué par rapport à un dictionnaire qui contient les clés nom de groupe, nom_noeud_hôte,
num_processus, nom du programmeet here. (le répertoire du fichier de configuration supervisé).
NOTE:
Il n'est pas possible que deux processus partagent un même fichier journal (fichier_journal_stdout)
lors de la rotation (stdout_logfile_maxbytes) est autorisé. Cela se traduira par le fichier
être corrompu.
Réglage par défaut: AUTO
Requis: Non
Introduit: 3.0, remplace les 2.0 fichier journal
stdout_logfile_maxbytes
Le nombre maximal d'octets pouvant être consommés par fichier_journal_stdout avant qu'il ne soit tourné
(des multiplicateurs de suffixe tels que "KB", "MB" et "GB" peuvent être utilisés dans la valeur). Réglez ceci
valeur à 0 pour indiquer une taille de journal illimitée.
Réglage par défaut: 50MB
Requis: Non
Introduit: 3.0, remplace les 2.0 fichier journal_maxoctets
stdout_logfile_backups
Le nombre de fichier_journal_stdout sauvegardes à conserver résultant du journal stdout du processus
rotation des fichiers. S'il est défini sur 0, aucune sauvegarde ne sera conservée.
Réglage par défaut10
Requis: Non
Introduit: 3.0, remplace les 2.0 fichier_journal_sauvegardes
stdout_capture_maxbytes
Nombre maximum d'octets écrits pour capturer FIFO lorsque le processus est en "mode de capture stdout"
(voir capture_mode). Doit être un entier (suffixe multiplicateurs comme "KB", "MB" et "GB"
peut être utilisé dans la valeur). Si cette valeur est 0, le mode de capture de processus sera désactivé.
Réglage par défaut0
Requis: Non
Introduit: 3.0, remplace les 2.0 fichier_journal_sauvegardes
stdout_events_enabled
Si vrai, les événements PROCESS_LOG_STDOUT seront émis lorsque le processus écrit dans son
descripteur de fichier stdout. Les événements ne seront émis que si le descripteur de fichier n'est pas
en mode capture au moment de la réception des données (voir capture_mode).
Réglage par défaut0
Requis: Non
Introduit: 3.0a7
fichier_journal stderr
Mettez la sortie du processus stderr dans ce fichier à moins que redirect_stderr est vrai. Accepte le
mêmes types de valeur que fichier_journal_stdout et peut contenir les mêmes expressions de chaîne Python.
NOTE:
Il n'est pas possible que deux processus partagent un même fichier journal (fichier_journal stderr)
lors de la rotation (stderr_logfile_maxbytes) est autorisé. Cela se traduira par le fichier
être corrompu.
Réglage par défaut: AUTO
Requis: Non
Introduit3.0
stderr_logfile_maxbytes
Le nombre maximal d'octets avant la rotation du fichier journal pour fichier_journal stderr. Accepte le
mêmes types de valeur que stdout_logfile_maxbytes.
Réglage par défaut: 50MB
Requis: Non
Introduit3.0
stderr_logfile_backups
Le nombre de sauvegardes à conserver résultant de la rotation du fichier journal stderr du processus.
S'il est défini sur 0, aucune sauvegarde ne sera conservée.
Réglage par défaut10
Requis: Non
Introduit3.0
stderr_capture_maxbytes
Nombre maximum d'octets écrits pour capturer FIFO lorsque le processus est en "mode de capture stderr"
(voir capture_mode). Doit être un entier (suffixe multiplicateurs comme "KB", "MB" et "GB"
peut être utilisé dans la valeur). Si cette valeur est 0, le mode de capture de processus sera désactivé.
Réglage par défaut0
Requis: Non
Introduit3.0
stderr_events_enabled
Si vrai, les événements PROCESS_LOG_STDERR seront émis lorsque le processus écrit dans son
descripteur de fichier stderr. Les événements ne seront émis que si le descripteur de fichier n'est pas
en mode capture au moment de la réception des données (voir capture_mode).
Réglage par défaut: faux
Requis: Non
Introduit: 3.0a7
convivial
Une liste de paires clé/valeur sous la forme KEY="val", KEY2="val2" qui sera placé dans le
l'environnement du processus enfant. La chaîne d'environnement peut contenir une chaîne Python
expressions qui seront évaluées par rapport à un dictionnaire contenant nom de groupe,
nom_noeud_hôte, num_processus, nom du programmeet here. (l'annuaire du superviseur
fichier de configuration). Les valeurs contenant des caractères non alphanumériques doivent être entre guillemets (par ex.
KEY="val:123",KEY2="val,456"). Sinon, la citation des valeurs est facultative mais
recommandé. Note que le sous-processus héritera des variables d'environnement du
shell utilisé pour démarrer "supervisord" à l'exception de ceux remplacés ici. Voir
environnement_sous-processus.
Réglage par défaut: Pas d'environnement supplémentaire
Requis: Non
Introduit3.0
annuaire
Un chemin de fichier représentant un répertoire auquel superviseur devrait temporairement chdir
avant d'exécuter l'enfant.
Réglage par défaut: Pas de chdir (hériter du superviseur)
Requis: Non
Introduit3.0
umask
Un nombre octal (par exemple 002, 022) représentant l'umask du processus.
Réglage par défaut: Pas d'umask spécial (hériter du superviseur)
Requis: Non
Introduit3.0
URL du serveur
L'URL transmise dans l'environnement au processus de sous-processus en tant que SUPERVISOR_SERVER_URL
(voir superviseur.childutils) pour permettre au sous-processus de communiquer facilement avec le
serveur HTTP interne. S'il est fourni, il doit avoir la même syntaxe et la même structure que le
[superviseur] option de section du même nom. S'il est réglé sur AUTO ou n'est pas réglé,
le superviseur construira automatiquement une URL de serveur, en privilégiant un serveur
qui écoute sur les sockets du domaine UNIX plutôt que sur celui qui écoute sur une socket Internet.
Réglage par défaut: AUTOMATIQUE
Requis: Non
Introduit3.0
[programme : x] Blog Exemple
[programme:chat]
commande =/bin/chat
nom_processus=%(nom_programme)s
nombreprocs=1
répertoire=/ Tmp
masque=022
priorité = 999
démarrage automatique = vrai
redémarrage automatique=inattendu
secondes de démarrage=10
tentatives de démarrage=3
codes de sortie=0,2
signal d'arrêt=TERME
stopwaitsecs=10
stopasgroup = faux
killasgroup=faux
utilisateur=chrême
redirect_stderr = faux
stdout_logfile=/a/chemin
stdout_logfile_maxbytes=1 Mo
stdout_logfile_backups=10
stdout_capture_maxbytes=1 Mo
stdout_events_enabled=false
stderr_logfile=/un/chemin
stderr_logfile_maxbytes=1 Mo
stderr_logfile_backups=10
stderr_capture_maxbytes=1 Mo
stderr_events_enabled = faux
environnement=A="1",B="2"
URLserveur=AUTO
[comprendre] Blog Paramètres
Le manuel de formation superviseur.conf le fichier peut contenir une section nommée [comprendre]. Si la configuration
le fichier contient un [comprendre] section, il doit contenir une seule clé nommée "files". Les
les valeurs de cette clé spécifient d'autres fichiers de configuration à inclure dans le
configuration.
[comprendre] Blog Nos valeurs
fichiers
Une séquence de globs de fichiers séparés par des espaces. Chaque glob de fichier peut être absolu ou relatif.
Si le fichier glob est relatif, il est considéré comme relatif à l'emplacement du
fichier de configuration qui l'inclut. Un "glob" est un modèle de fichier qui correspond à un
modèle spécifié selon les règles utilisées par le shell Unix. Aucune extension de tilde n'est
fait, mais *, ?, et les plages de caractères exprimées avec [] sera correctement mis en correspondance.
Les inclusions récursives des fichiers inclus ne sont pas prises en charge.
Réglage par défaut: Pas de valeur par défaut (obligatoire)
Requis: Oui.
Introduit3.0
[comprendre] Blog Exemple
[comprendre]
files = /an/absolute/filename.conf /an/absolute/*.conf foo.conf config??.conf
[groupe : x] Blog Paramètres
Il est souvent utile de regrouper des groupes de processus « homogènes » (alias « programmes ») dans un
groupe de processus « hétérogène » afin qu'ils puissent être contrôlés comme une unité à partir du superviseur
diverses interfaces de contrôleur.
Pour placer des programmes dans un groupe afin de pouvoir les traiter comme une unité, définissez un [groupe : x]
dans votre fichier de configuration. La valeur d'en-tête de groupe est un composite. c'est le mot
"group", suivi directement de deux points, puis du nom du groupe. Une valeur d'en-tête de [groupe:toto]
décrit un groupe avec le nom de "foo". Le nom est utilisé dans les applications clientes
qui contrôlent les processus créés à la suite de cette configuration. C'est un
erreur pour créer un groupe section qui n'a pas de nom. Le nom ne doit pas comporter de
caractère deux-points ou un caractère crochet.
Un [groupe : x], il doit y avoir un ou plusieurs [programme : x] sections ailleurs dans votre
fichier de configuration, et le groupe doit s'y référer par leur nom dans le tout proche. valeur.
Si des groupes de processus "homogènes" (représentés par des sections de programme) sont placés dans un
groupe « hétérogène » via [groupe : x] sections tout proche. droite, les groupes homogènes qui
sont impliqués par la section de programme n'existeront pas au moment de l'exécution dans le superviseur. Au lieu de cela, tout
les processus appartenant à chacun des groupes homogènes seront placés dans le
groupe hétérogène. Par exemple, étant donné la configuration de groupe suivante :
[groupe:toto]
programmes=bar,baz
priorité = 999
Compte tenu de ce qui précède, au démarrage supervisé, le Bar et baz des groupes homogènes ne
existent, et les processus qui auraient été sous eux seront maintenant déplacés dans le foo
groupe.
[groupe : x] Blog Nos valeurs
tout proche.
Une liste de noms de programmes séparés par des virgules. Les programmes qui sont répertoriés deviennent membres
du groupe.
Réglage par défaut: Pas de valeur par défaut (obligatoire)
Requis: Oui.
Introduit3.0
priorité
Un numéro de priorité analogue à un [programme : x] valeur prioritaire attribuée au groupe.
Réglage par défaut999
Requis: Non
Introduit3.0
[groupe : x] Blog Exemple
[groupe:toto]
programmes=bar,baz
priorité = 999
[fcgi-programme:x] Blog Paramètres
Le superviseur peut gérer des groupes de FastCGI processus qui écoutent tous sur le même socket.
Jusqu'à présent, la flexibilité de déploiement de FastCGI était limitée. Pour obtenir le processus complet
gestion, vous pouviez utiliser mod_fastcgi sous Apache mais vous étiez alors bloqué avec Apache
modèle de concurrence inefficace d'un processus ou d'un thread par connexion. En plus de
nécessitant plus de ressources CPU et mémoire, le processus/thread par modèle de connexion peut être
rapidement saturé par une ressource lente, empêchant d'autres ressources d'être servies. Dans
afin de tirer parti des nouveaux serveurs Web événementiels tels que lighttpd ou nginx qui
n'incluez pas de gestionnaire de processus intégré, vous deviez utiliser des scripts comme cgi-fcgi ou
spawn-fcgi. Ceux-ci peuvent être utilisés en conjonction avec un gestionnaire de processus tel que Supervisord
ou daemontools, mais nécessite que chaque processus enfant FastCGI se lie à son propre socket. Les
les inconvénients de ceci sont : une configuration de serveur Web inutilement compliquée, peu gracieuse
redémarrages et une tolérance aux pannes réduite. Avec moins de sockets à configurer, le serveur Web
les configurations sont beaucoup plus petites si des groupes de processus FastCGI peuvent partager des sockets. partagé
les sockets permettent des redémarrages en douceur car le socket reste lié par le processus parent
pendant le redémarrage de l'un des processus enfants. Enfin, les sockets partagés sont plus
tolérant aux pannes car si un processus donné échoue, d'autres processus peuvent continuer à servir
connexions entrantes.
Avec la prise en charge intégrée de la génération FastCGI, Supervisor vous offre le meilleur des deux mondes.
Vous obtenez une gestion complète des processus avec des groupes de processus FastCGI partageant des sockets
sans être lié à un serveur Web particulier. C'est une séparation nette des préoccupations,
permettant au serveur Web et au gestionnaire de processus de faire chacun ce qu'ils font le mieux.
NOTE:
Le gestionnaire de sockets dans Supervisor a été développé à l'origine pour prendre en charge les processus FastCGI
mais il n'est pas limité à FastCGI. D'autres protocoles peuvent également être utilisés sans
configuration. Tout programme qui peut accéder à un socket ouvert à partir d'un descripteur de fichier (par exemple
avec socket.fromfd en Python) peut utiliser le gestionnaire de sockets. Le superviseur
créer automatiquement le socket, lier et écouter avant de forker le premier enfant dans un
grouper. Le socket sera passé à chaque enfant sur le numéro de descripteur de fichier 0 (zéro).
Lorsque le dernier enfant du groupe sort, Supervisor ferme le socket.
Toutes les options disponibles pour [programme : x] les sections sont également respectées par programme-fcgi
sections.
[fcgi-programme:x] Blog Nos valeurs
[fcgi-programme:x] sections ont une seule clé qui [programme : x] les sections n'ont pas.
douille
Le socket FastCGI pour ce programme, soit le socket de domaine TCP ou UNIX. Pour les sockets TCP,
utilisez ce format : tcp://localhost:9002. Pour les sockets de domaine UNIX, utilisez
unix:///absolute/chemin/vers/fichier.sock. Les expressions de chaîne sont évaluées par rapport à un
dictionnaire contenant les clés "nom_programme" et "ici" (le répertoire du
fichier de configuration supervisé).
Réglage par défaut: Aucun défaut.
Requis: Oui.
Introduit3.0
propriétaire_de_socket
Pour les sockets de domaine UNIX, ce paramètre peut être utilisé pour spécifier l'utilisateur et le groupe pour
le socket FastCGI. Peut être un nom d'utilisateur UNIX (par exemple chrism) ou un nom d'utilisateur et un groupe UNIX
séparés par deux points (par exemple chrism:wheel).
Réglage par défaut: Utilise l'utilisateur et le groupe définis pour le programme fcgi
Requis: Non
Introduit3.0
mode_socket
Pour les sockets de domaine UNIX, ce paramètre peut être utilisé pour spécifier le mode d'autorisation.
Réglage par défaut0700
Requis: Non
Introduit3.0
Consulter [programme : x] Blog Paramètres pour les autres clés autorisées, delta les contraintes ci-dessus
et des ajouts.
[fcgi-programme:x] Blog Exemple
[programme-fcgi : nom du programme fcgi]
command=/usr/bin/exemple.fcgi
socket=unix:///var/run/supervisor/%(nom_programme)s.sock
socket_owner=chrême
socket_mode=0700
nom_processus=%(nom_programme)s_%(numéro_processus)02d
nombreprocs=5
répertoire=/ Tmp
masque=022
priorité = 999
démarrage automatique = vrai
redémarrage automatique=inattendu
secondes de démarrage=1
tentatives de démarrage=3
codes de sortie=0,2
stopsignal=QUITTER
stopasgroup = faux
killasgroup=faux
stopwaitsecs=10
utilisateur=chrême
redirect_stderr = vrai
stdout_logfile=/a/chemin
stdout_logfile_maxbytes=1 Mo
stdout_logfile_backups=10
stdout_events_enabled=false
stderr_logfile=/un/chemin
stderr_logfile_maxbytes=1 Mo
stderr_logfile_backups=10
stderr_events_enabled = faux
environnement=A="1",B="2"
URLserveur=AUTO
[écouteur d'événement : x] Blog Paramètres
Supervisor permet à des groupes de processus homogènes spécialisés (« pools d'écouteurs d'événements ») d'être
défini dans le fichier de configuration. Ces pools contiennent des processus destinés à
recevoir et répondre aux notifications d'événements du système d'événements du superviseur. Voir les événements pour
une explication du fonctionnement des événements et de la mise en œuvre de programmes pouvant être déclarés comme
auditeurs d'événements.
Notez que toutes les options disponibles pour [programme : x] les sections sont respectées par eventlistener
les sections sauf pour stdout_capture_maxbytes et stderr_capture_maxbytes (auditeurs d'événements
ne peut pas émettre d'événements de communication de processus, voir capture_mode).
[écouteur d'événement : x] Blog Nos valeurs
[écouteur d'événement : x] sections ont quelques clés qui [programme : x] les sections n'ont pas.
taille_tampon
Taille de la mémoire tampon de la file d'attente d'événements du pool d'écouteurs d'événements. Lorsque le tampon d'événements d'un pool d'écouteurs
est débordé (comme cela peut arriver lorsqu'un pool d'écouteurs d'événements ne peut pas suivre tous les
événements qui lui sont envoyés), l'événement le plus ancien dans la mémoire tampon est rejeté.
l'évènementiel
Une liste séparée par des virgules des noms de types d'événements auxquels cet écouteur est « intéressé »
recevoir des notifications pour (voir event_types pour une liste des noms de type d'événement valides).
gestionnaire_résultat
A pkg_ressources entrée point un magnifique qui se résout en un appelable Python. Le défaut
valeur est superviseur.dispatchers:default_handler. Spécification d'un résultat alternatif
gestionnaire est une chose très rare à faire, et par conséquent, comment en créer un est
non documenté.
Consulter [programme : x] Blog Paramètres pour les autres clés autorisées, delta les contraintes ci-dessus
et des ajouts.
[écouteur d'événement : x] Blog Exemple
[écouteur d'événements : nom de l'écouteur d'événements]
commande=/bin/eventlistener
nom_processus=%(nom_programme)s_%(numéro_processus)02d
nombreprocs=5
événements=PROCESS_STATE
taille_tampon=10
répertoire=/ Tmp
masque=022
priorité=-1
démarrage automatique = vrai
redémarrage automatique=inattendu
secondes de démarrage=1
tentatives de démarrage=3
codes de sortie=0,2
stopsignal=QUITTER
stopwaitsecs=10
stopasgroup = faux
killasgroup=faux
utilisateur=chrême
redirect_stderr = faux
stdout_logfile=/a/chemin
stdout_logfile_maxbytes=1 Mo
stdout_logfile_backups=10
stdout_events_enabled=false
stderr_logfile=/un/chemin
stderr_logfile_maxbytes=1 Mo
stderr_logfile_backups=10
stderr_events_enabled = faux
environnement=A="1",B="2"
URLserveur=AUTO
[interface rpc : x] Blog Paramètres
L'ajout de interface rpc:x paramètres dans le fichier de configuration n'est utile que pour les personnes qui
souhaitez étendre le superviseur avec un comportement personnalisé supplémentaire.
Dans l'exemple de fichier de configuration, il y a une section qui est nommée [rpcinterface:superviseur].
Par défaut, cela ressemble à ce qui suit.
[rpcinterface:superviseur]
superviseur.rpcinterface_factory = superviseur.rpcinterface:make_main_rpcinterface
Le manuel de formation [rpcinterface:superviseur] doit rester dans la configuration pour la norme
configuration du superviseur pour qu'il fonctionne correctement. Si vous ne voulez pas que le superviseur fasse quoi que ce soit, il
ne fait pas déjà hors de la boîte, c'est tout ce que vous devez savoir sur ce type de
.
Cependant, si vous souhaitez ajouter des espaces de noms d'interface rpc afin de personnaliser le superviseur, vous
peut ajouter d'autres [interface rpc:foo] sections, où "foo" représente l'espace de noms de
l'interface (depuis la racine Web), et la valeur nommée par superviseur.rpcinterface_factory
est une usine appelable qui devrait avoir une signature de fonction qui accepte un seul
argument de position superviseur et autant d'arguments de mot-clé que nécessaire pour effectuer
configuration. Toute paire clé/valeur supplémentaire définie dans le [interface rpc : x] section sera
être passé en tant qu'arguments mot-clé à la fabrique.
Voici un exemple de fonction d'usine, créée dans le __init__.py fichier du Python
paquet mon colis.
à partir de my.package.rpcinterface importer AnotherRPCInterface
def make_another_rpcinterface(superviseur, **config):
tentatives = int(config.get('retries', 0))
other_rpc_interface = AnotherRPCInterface(supervisord, réessaye)
retourner une autre_rpc_interface
Et une section dans le fichier de configuration destinée à le configurer.
[rpcinterface:un autre]
superviseur.rpcinterface_factory = my.package:make_another_rpcinterface
tentatives = 1
[interface rpc : x] Blog Nos valeurs
superviseur.rpcinterface_factory
pkg_ressources "point d'entrée" nom en pointillé de la fonction d'usine de votre interface RPC.
Réglage par défaut: N / A
Requis: Non
Introduit3.0
[interface rpc : x] Blog Exemple
[rpcinterface:un autre]
superviseur.rpcinterface_factory = my.package:make_another_rpcinterface
tentatives = 1
Sous-processus
superviseurL'objectif principal de est de créer et de gérer des processus basés sur les données de son
fichier de configuration. Il le fait en créant des sous-processus. Chaque sous-processus généré par
superviseur est géré pendant toute sa durée de vie par superviseurd (superviseur est le
processus parent de chaque processus qu'il crée). Lorsqu'un enfant décède, le superviseur est avisé de
sa mort par le SIGCHLD signal, et il effectue l'opération appropriée.
Non démoniaque of Sous-processus
Les programmes destinés à être exécutés sous superviseur ne doivent pas se démoniser eux-mêmes. Au lieu de cela, ils
devrait fonctionner au premier plan. Ils ne doivent pas se détacher du terminal dont ils
sont démarrés.
Le moyen le plus simple de savoir si un programme s'exécutera au premier plan est d'exécuter la commande qui
invoque le programme à partir d'une invite de shell. S'il vous redonne le contrôle du terminal,
mais continue de courir, il se démonise et ce sera presque certainement le mauvais
façon de l'exécuter sous superviseur. Vous souhaitez exécuter une commande qui nécessite essentiellement de vous
presser Ctrl-C pour reprendre le contrôle du terminal. S'il vous renvoie une invite de shell
après l'avoir exécuté sans avoir besoin d'appuyer Ctrl-C, ce n'est pas utile sous superviseur. Tous
les programmes ont des options pour être exécutés au premier plan mais il n'y a pas de « moyen standard » de le faire ;
vous devrez lire la documentation de chaque programme.
Vous trouverez ci-dessous des exemples de fichiers de configuration connus pour démarrer des programmes courants dans
mode "premier plan" sous Superviseur.
Exemples of Programme Configurations
Voici quelques exemples de configuration de programme « du monde réel » :
Apache 2.2.6
[programme:apache2]
command=/chemin/vers/httpd -c "ErrorLog /dev/stdout" -DFOREGROUND
redirect_stderr = vrai
Deux Zopé 2.X cas et UN ZEO serveur
[programme:zeo]
command=/chemin/vers/runzeo
priorité = 1
[programme:zope1]
command=/chemin/vers/instance/home/bin/runzope
priorité = 2
redirect_stderr = vrai
[programme:zope2]
command=/chemin/vers/une autre/instance/home/bin/runzope
priorité = 2
redirect_stderr = vrai
Postgres 8.X
[programme:postgres]
command=/chemin/vers/postmaster
; nous utilisons le signal d'arrêt "rapide" SIGINT
signal d'arrêt=INT
redirect_stderr = vrai
OpenLDAP giflé
[programme:slapd]
command=/chemin/vers/slapd -f /chemin/vers/slapd.conf -h ldap://0.0.0.0:8888
redirect_stderr = vrai
Autres Exemples
D'autres exemples de scripts shell qui pourraient être utilisés pour démarrer des services sous superviseur Vous pouvez
être trouvé à http://thedjbway.b0llix.net/services.html. Ces exemples sont en fait pour
Daemon Tools mais le principe est le même pour le superviseur.
Une autre collection de recettes pour démarrer divers programmes au premier plan est disponible
grâce au http://smarden.org/runit/runscripts.html.
pidproxy Programme
Certains processus (comme mysqld) ignorer les signaux envoyés au processus réel qui est engendré par
superviseur. Au lieu de cela, un thread/processus "spécial" est créé par ces types de programmes
qui est responsable du traitement des signaux. Ceci est problématique car superviseur Vous pouvez
ne tue qu'un processus qu'il crée lui-même. Si un processus créé par superviseur crée des
ses propres processus enfants, superviseur ne peut pas les tuer.
Heureusement, ces types de programmes écrivent généralement un "pidfile" qui contient les
PID du processus "spécial", et est destiné à être lu et utilisé afin de tuer le processus. Comme
une solution de contournement pour ce cas, un pidproxy le programme peut gérer le démarrage de ce type
de processus. Les pidproxy programme est une petite cale qui démarre un processus, et sur le
réception d'un signal, envoie le signal au pid fourni dans un fichier pid. Un échantillon
L'entrée du programme de configuration pour un programme compatible pidproxy est fournie ci-dessous.
[programme:mysql]
command=/chemin/vers/pidproxy /chemin/vers/pidfile /chemin/vers/mysqld_safe
Le manuel de formation pidproxy programme est mis dans votre configuration $BINDIR lorsque le superviseur est installé
(c'est un "script de console").
Sous-processus Environnement
Les sous-processus hériteront de l'environnement du shell utilisé pour démarrer le superviseur
programme. Plusieurs variables d'environnement seront définies par superviseur lui-même chez l'enfant
l'environnement aussi, y compris SUPERVISOR_ENABLED (un drapeau indiquant que le processus est en cours
contrôle du superviseur), SUPERVISOR_PROCESS_NAME (le nom de processus spécifié par le fichier de configuration pour
ce processus) et SUPERVISOR_GROUP_NAME (le nom du groupe de processus spécifié par le fichier de configuration pour
le processus enfant).
Ces variables d'environnement peuvent être remplacées dans le [superviseur] configuration de la section
option nommée convivial (s'applique à tous les sous-processus) ou dans le [programme : x]
convivial option de configuration (s'applique uniquement au sous-processus spécifié dans le
[programme : x] section). Ces paramètres "d'environnement" sont additifs. En d'autres termes, chaque
l'environnement du sous-processus consistera en :
Les variables d'environnement définies dans le shell utilisées pour démarrer Supervisord...
... ajouté/remplacé par ...
... le convivial les variables set dans les le convivial de défis
option de configuration...
... ajouté/remplacé par ...
... propre au superviseur convivial les variables
(SUPERVISOR_ENABLED, SUPERVISOR_PROCESS_NAME, SUPERVISOR_GROUP_NAME) ..
... ajouté/remplacé par ...
... le convivial les variables set dans les le par processus
option de configuration "environnement".
Aucun shell n'est exécuté par superviseur quand il exécute un sous-processus, donc les variables d'environnement
tel que UTILISATEUR, PATH, ACCUEIL, SHELL, NOM DU JOURNAL, etc. ne sont pas modifiés par rapport à leurs valeurs par défaut ou
autrement réaffecté. Ceci est particulièrement important à noter lorsque vous exécutez un
programme d'un superviseur exécuter en tant que root avec un utilisateur = strophe dans la configuration. contrairement à
cron, superviseur n'essaye pas de deviner et d'outrepasser l'environnement « fondamental »
des variables comme UTILISATEUR, PATH, ACCUEILet NOM DU JOURNAL lorsqu'il effectue un setuid à l'utilisateur défini
au sein du utilisateur = option de configuration du programme. Si vous devez définir des variables d'environnement pour un
programme particulier qui pourrait autrement être défini par une invocation du shell pour un
utilisateur, vous devez le faire explicitement dans le environnement= option de configuration du programme. Un exemple
de définir ces variables d'environnement est comme ci-dessous.
[programme:apache2]
command=/home/chrism/bin/httpd -c "ErrorLog /dev/stdout" -DFOREGROUND
utilisateur=chrême
environnement=HOME="/home/chrism",USER="chrism"
Processus États
Un processus contrôlé par Supervisord sera dans l'un des états ci-dessous à un moment donné.
Vous pouvez voir ces noms d'état dans divers éléments de l'interface utilisateur des clients.
ARRÊTÉ (0)
Le processus a été arrêté en raison d'une demande d'arrêt ou n'a jamais été démarré.
DÉPART (10)
Le processus démarre en raison d'une demande de démarrage.
RUNNING (20)
Le processus est en cours.
RETOUR (30)
Le processus est entré dans le DÉPART état mais par la suite sorti trop rapidement pour passer à
le RUNNING Etat.
ARRÊT (40)
Le processus s'arrête en raison d'une demande d'arrêt.
SORTI (100)
Le processus est sorti de la RUNNING état (prévu ou inattendu).
MORTEL (200)
Le processus n'a pas pu être démarré avec succès.
INCONNU (1000)
Le processus est dans un état inconnu (superviseur erreur de programmation).
Chaque processus exécuté sous le superviseur progresse à travers ces états conformément à ce qui suit
Graphique dirigé.
[image : Graphique de transition d'état de sous-processus] [image] Transition d'état de sous-processus
Graphique.UNINDENT
Un processus est en cours ARRÊTÉ indiquer s'il a été arrêté administrativement ou s'il a
jamais commencé.
Lorsqu'un processus de redémarrage automatique est en cours RETOUR état, il sera automatiquement
redémarré par superviseur. Il basculera entre DÉPART et RETOUR déclare jusqu'à ce qu'il
devient évident qu'il ne peut pas être démarré parce que le nombre de tentatives de démarrage a
dépassé le maximum, à quel point il passera au MORTEL Etat. Chaque démarrage
réessayer prendra progressivement plus de temps.
Lorsqu'un processus est en SORTI état, il redémarrera automatiquement :
· jamais si c'est redémarrage automatique paramètre est défini sur non.
· inconditionnellement si son redémarrage automatique paramètre est défini sur oui.
· conditionnellement si son redémarrage automatique paramètre est défini sur inattendu. S'il est sorti avec un
code de sortie qui ne correspond pas à l'un des codes de sortie définis dans le codes de sortie
paramètre de configuration du processus, il sera redémarré.
Un processus passe automatiquement de SORTI à RUNNING suite à la configuration
pour redémarrer automatiquement de manière conditionnelle ou inconditionnelle. Le nombre de transitions entre
RUNNING et SORTI n'est limité en aucune façon : il est possible de créer une configuration
qui redémarre sans cesse un processus terminé. C'est une fonctionnalité, pas un bug.
Un processus redémarré automatiquement ne sera jamais redémarré automatiquement s'il se termine dans le MORTEL
état (il doit être redémarré manuellement à partir de cet état).
Un processus passe au ARRÊT l'état via une demande d'arrêt administratif, et
puis finir dans le ARRÊTÉ Etat.
Un processus qui ne peut pas être arrêté avec succès restera dans le ARRÊT état pour toujours.
Cette situation ne doit jamais être atteinte pendant les opérations normales car elle implique que le
processus n'a pas répondu à une décision finale SIGTUER signal qui lui est envoyé par le superviseur, qui est
"impossible" sous UNIX.
Les transitions d'état qui nécessitent toujours une action de l'utilisateur pour être invoquées sont les suivantes :
MORTEL -> DÉPART
RUNNING -> ARRÊT
Les transitions d'état qui nécessitent généralement, mais pas toujours, une action de l'utilisateur pour être invoquées sont
ceux-ci, à quelques exceptions près :
ARRÊTÉ -> DÉPART (sauf au démarrage supervisé si le processus est configuré pour démarrer automatiquement)
SORTI -> DÉPART (sauf si le processus est configuré pour redémarrer automatiquement)
Toutes les autres transitions d'état sont gérées automatiquement par Supervisord.
Journal
L'une des principales tâches qui superviseur effectue est la journalisation. superviseur enregistre une activité
log détaillant ce qu'il fait pendant qu'il s'exécute. Il enregistre également le processus enfant stdout et stderr
sortie vers d'autres fichiers si configuré pour le faire.
Activité Historique
Le journal d'activité est l'endroit où superviseur enregistre des messages sur sa propre santé, ses
les changements d'état du sous-processus, tous les messages résultant d'événements, et le débogage et
messages d'information. Le chemin d'accès au journal d'activité est configuré via le fichier journal
paramètre dans la [superviseur] section du fichier de configuration, par défaut
$CWD/superviseur.log. Un exemple de trafic de journal d'activité est présenté dans l'exemple ci-dessous. Quelques
les lignes ont été brisées pour mieux s'adapter à l'écran.
Échantillon Activité Historique Sortie
2007-09-08 14:43:22,886 DEBG 127.0.0.1:Medusa (V1.11) a commencé le samedi 8 septembre 14:43:22 2007
Nom d'hôte : kingfish
Port: 9001
2007-09-08 14:43:22,961 INFO RPC interface 'superviseur' initialisé
2007-09-08 14:43:22,961 CRIT s'exécutant sans aucune vérification d'authentification HTTP
2007-09-08 14:43:22,962 INFO Supervisord a commencé avec le pid 27347
2007-09-08 14:43:23,965 INFO engendrée : 'listener_00' avec pid 27349
2007-09-08 14:43:23,970 INFO engendrée: 'eventgen' avec pid 27350
2007-09-08 14:43:23,990 INFO engendrée: 'cultivateur' avec pid 27351
2007-09-08 14:43:24,059 DEBG 'listener_00' sortie stderr :
/Users/chrism/projects/supervisor/supervisor2/dev-sandbox/bin/python :
impossible d'ouvrir le fichier '/Users/chrism/projects/supervisor/supervisor2/src/supervisor/scripts/osx_eventgen_listener.py' :
[Errno 2] Aucun fichier ou répertoire de ce type
2007-09-08 14:43:24,060 DEBG fd 7 fermé, surveillance arrêtée
(sortie standard)>
2007-09-08 14:43:24,060 INFO quittée : listener_00 (état de sortie 2 ; non attendu)
2007-09-08 14:43:24,061 DEBG a reçu SIGCHLD indiquant qu'un enfant a arrêté
Le journal d'activité "niveau" est configuré dans le fichier de configuration via le loglevel paramètre dans
le [superviseur] section du fichier ini. Lorsque loglevel est défini, les messages du spécifié
priorité, ainsi que ceux ayant une priorité plus élevée sont enregistrés dans le journal d'activité. Pour
exemple, si loglevel is erreur, messages de erreur et critique la priorité sera enregistrée.
Cependant, si le niveau de journalisation est prévenir, messages de prévenir, erreuret critique sera enregistré.
Activité Historique Niveaux
Le tableau ci-dessous décrit les niveaux de journalisation plus en détail, classés selon la priorité la plus élevée
au plus bas. La « valeur du fichier de configuration » est la chaîne fournie au loglevel paramètre dans
le [superviseur] section du fichier de configuration et le « code de sortie » est le code qui
apparaît dans les lignes de sortie du journal d'activité.
?? ??
│Valeur du fichier de configuration │ Code de sortie │ Description │
?? ??
│critique │ CRIT │ Messages indiquant un │
│ │ │ condition qui nécessite │
│ │ │ utilisateur immédiat │
│ │ attention, un superviseur │
│ │ │ changement d'état, ou un │
│ │ │ erreur dans le superviseur │
│ │ │ lui-même. ??
?? ??
│erreur │ ERRO │ Messages qui indiquent un │
│ │ │ potentiellement ignorable │
│ │ │ condition d'erreur (par exemple │
│ │ │ impossible d'effacer un journal │
│ │ répertoire). ??
?? ??
│WARN │ WARN │ Messages indiquant │
│ │ │ une condition anormale │
│ │ │ qui n'est pas une erreur. ??
?? ??
│info │ INFO │ Information normale │
│ │ │ sortie. C'est le
│ │ │ niveau de journalisation par défaut si │
│ │ │ aucun n'est explicitement │
│ │ configuré. ??
?? ??
debug │ DEBG │ Messages utiles pour │
│ │ │ utilisateurs essayant de déboguer │
│ │ │ configuration du processus │
│ │ et communication │
│ │ comportement (processus │
│ │ │ sortie, état de l'auditeur │
│ │ │ changements, événement │
│ │ notifications). ??
?? ??
│trace │ TRAC │ Messages utiles pour │
│ │ développeurs essayant de │
│ │ │ superviseur de débogage │
│ │ │ plugins, et informations │
│ │ à propos de HTTP et RPC │
│ │ demandes et réponses. ??
?? ??
blather │ BLAT │ Messages utiles pour │
│ │ développeurs essayant de │
│ │ │ superviseur de débogage lui-même. ??
?? ??
Activité Historique Rotation
Le journal d'activité est « tourné » de superviseur basé sur la combinaison des
fichier journal_maxoctets et la fichier_journal_sauvegardes paramètres dans le [superviseur] l'article de l'
fichier de configuration. Lorsque le journal d'activité atteint fichier journal_maxoctets octets, le journal actuel
est déplacé vers un fichier de sauvegarde et un nouveau fichier journal d'activité est créé. Quand cela arrive,
si le nombre de fichiers de sauvegarde existants est supérieur ou égal à fichier_journal_sauvegardes, la
le fichier de sauvegarde le plus ancien est supprimé et les fichiers de sauvegarde sont renommés en conséquence. Si le fichier
à qui l'on écrit est nommé journal.supervisé, quand il dépasse fichier journal_maxoctets, c'est fermé
et renommé en superviseur.log.1, et si les fichiers superviseur.log.1, superviseur.log.2 et ainsi de suite
existent, puis ils sont renommés en superviseur.log.2, superviseur.log.3 etc. respectivement.
If fichier journal_maxoctets est 0, le fichier journal n'est jamais tourné (et donc les sauvegardes ne sont jamais effectuées).
If fichier_journal_sauvegardes est 0, aucune sauvegarde ne sera conservée.
Enfant Processus Journaux
La sortie standard des processus enfants générés par le superviseur, par défaut, est capturée pour réaffichage
aux utilisateurs de superviseur et d'autres clients. Si aucune configuration spécifique liée au fichier journal
est réalisée dans un [programme : x], [fcgi-programme:x], ou [écouteur d'événement : x] section dans le
fichier de configuration, ce qui suit est vrai :
· superviseur capturera la sortie stdout et stderr du processus enfant dans un fichier temporaire
des dossiers. Chaque flux est capturé dans un fichier séparé. Ceci est connu comme AUTO mode journal.
· AUTO les fichiers journaux sont nommés automatiquement et placés dans le répertoire configuré comme
rép du journal des enfants du système [superviseur] section du fichier de configuration.
· La taille de chacun AUTO fichier journal est délimité par le {nom du flux}_logfile_maxbytes valeur de
la section du programme (où {streamname} est "stdout" ou "stderr"). Quand il atteint cela
numéro, il est tourné (comme le journal d'activité), en fonction du
{nom du flux}_logfile_backups.
Les clés de configuration qui influencent la connexion au processus enfant [programme : x] et
[fcgi-programme:x] les sections sont les suivantes :
redirect_stderr, fichier_journal_stdout, stdout_logfile_maxbytes, stdout_logfile_backups,
stdout_capture_maxbytes, fichier_journal stderr, stderr_logfile_maxbytes, stderr_logfile_backups
et stderr_capture_maxbytes.
On peut définir fichier_journal_stdout or fichier_journal stderr à la chaîne spéciale "syslog". Dans ce cas,
les journaux seront acheminés vers le service syslog au lieu d'être enregistrés dans des fichiers.
[écouteur d'événement : x] les sections peuvent ne pas spécifier redirect_stderr, stdout_capture_maxbytes, ou
stderr_capture_maxbytes, mais sinon ils acceptent les mêmes valeurs.
Les clés de configuration qui influencent la journalisation du processus enfant dans le [superviseur] config
section du fichier sont ceux-ci : rép du journal des enfantset pas de nettoyage.
Capture Mode
Le mode capture est une fonctionnalité avancée de Supervisor. Vous n'avez pas besoin de comprendre le mode capture
à moins que vous ne vouliez prendre des mesures en fonction des données analysées à partir de la sortie du sous-processus.
Si un [programme : x] section dans le fichier de configuration définit une valeur non nulle
stdout_capture_maxbytes or stderr_capture_maxbytes paramètre, chaque processus représenté par
la section programme peut émettre des jetons spéciaux sur son flux stdout ou stderr (respectivement)
ce qui amènera effectivement le superviseur à émettre un PROCESS_COMMUNICATION événement (voir événements
pour une description des événements).
Le protocole de communication du processus repose sur deux balises, une qui commande au superviseur de
entrez « mode de capture » pour le flux et celui qui lui commande de quitter. Lorsqu'un processus
le flux passe en "mode capture", les données envoyées au flux seront envoyées dans un tampon séparé dans
mémoire, le "tampon de capture", qui est autorisé à contenir un maximum de capture_maxbytes
octets. En mode capture, lorsque la longueur du tampon dépasse capture_maxbytes octets, le
les données les plus anciennes dans la mémoire tampon sont supprimées pour faire de la place aux nouvelles données. Lorsqu'un flux de processus
quitte le mode capture, un PROCESS_COMMUNICATION le sous-type d'événement est émis par le superviseur, qui
peuvent être interceptés par des écouteurs d'événement.
La balise pour commencer le « mode de capture » dans un flux de processus est . La balise
pour quitter le mode capture est . Les données entre ces balises peuvent être
arbitraire et constitue la charge utile du PROCESS_COMMUNICATION un événement. Par exemple, si un
programme est mis en place avec un stdout_capture_maxbytes de "1 Mo", et il émet le message suivant sur
son flux stdout :
Salut!
Dans cette circonstance, superviseur émettra un PROCESS_COMMUNICATIONS_STDOUT événement avec
données dans la charge utile de "Hello!".
Un exemple de script (écrit en Python) qui émet un événement de communication de processus se trouve dans
le scripts répertoire du package superviseur, nommé sample_commevent.py.
La sortie des processus spécifiés comme « écouteurs d'événements » ([écouteur d'événement : x] sections) n'est pas
traité de cette façon. La sortie de ces processus ne peut pas entrer en mode capture.
Extension Superviseur XML-RPC API
Supervisor peut être étendu avec de nouvelles API XML-RPC. Déjà plusieurs plugins tiers
existent qui peuvent être câblés dans votre configuration Supervisor. Vous pouvez en plus écrire
le tien. Les interfaces XML-RPC extensibles sont une fonctionnalité avancée, introduite dans la version
3.0. Vous n'avez pas besoin de le comprendre, sauf si vous souhaitez utiliser un RPC tiers existant
plugin d'interface ou si vous souhaitez écrire votre propre plugin d'interface RPC.
Configuration XML-RPC Interface Usines de chars
Une interface RPC supplémentaire est configurée dans une installation de supervision en ajoutant un
[interface rpc : x] dans le fichier de configuration Supervisor.
Dans l'exemple de fichier de configuration, il y a une section qui est nommée [rpcinterface:superviseur].
Par défaut, cela ressemble à ceci :
[rpcinterface:superviseur]
superviseur.rpcinterface_factory = superviseur.rpcinterface:make_main_rpcinterface
Cette section doit rester dans la configuration pour que la configuration standard du superviseur fonctionne
correctement. Si vous ne voulez pas que le superviseur fasse quoi que ce soit, il ne le fait pas déjà
box, c'est tout ce que vous devez savoir sur ce type de section.
Cependant, si vous souhaitez ajouter des espaces de noms d'interface XML-RPC supplémentaires à une configuration de
superviseur, vous pouvez ajouter des [interface rpc:foo] sections, où "foo" représente le
l'espace de noms de l'interface (à partir de la racine Web), et la valeur nommée par
superviseur.rpcinterface_factory est un exécutable en usine écrit en Python qui devrait avoir
une signature de fonction qui accepte un seul argument positionnel superviseur et autant
arguments de mot-clé requis pour effectuer la configuration. Toute paire clé/valeur définie
au sein du interface rpc:toto La section sera transmise en tant qu'arguments de mot-clé à la fabrique.
Voici un exemple de fonction d'usine, créée dans le package mon colis.
def make_another_rpcinterface(superviseur, **config):
tentatives = int(config.get('retries', 0))
other_rpc_interface = AnotherRPCInterface(supervisord, réessaye)
retourner une autre_rpc_interface
Et une section dans le fichier de configuration destinée à le configurer.
[rpcinterface:un autre]
superviseur.rpcinterface_factory = my.package:make_another_rpcinterface
tentatives = 1
Glossaire
Daemon Tools
A processus des bactéries Système by DJ Bernstein.
lancé
A processus des bactéries Système d'utiliser by Apple comme processus 1 sous Mac OS X.
exécuter A processus des bactéries Système.
Superlance
Un package qui fournit diverses implémentations d'écouteurs d'événements qui se connectent à
Supervisor qui peut aider à surveiller l'utilisation de la mémoire du processus et l'état du plantage :
http://pypi.python.org/pypi/superlance.
umask Abréviation de utilisateur masque: définit le masque de création de mode fichier du processus en cours.
See http://en.wikipedia.org/wiki/Umask.
API DOCUMENTATION
XML-RPC API Documentation
Pour utiliser l'interface XML-RPC, connectez-vous au port HTTP du superviseur avec n'importe quel client XML-RPC
bibliothèque et exécutez des commandes contre elle. Un exemple de faire cela en utilisant Python xmlrpclib
la bibliothèque cliente est la suivante.
importer xmlrpclib
serveur = xmlrpclib.Server('http://localhost:9001/RPC2')
Vous pouvez appeler des méthodes contre superviseur et ses sous-processus en utilisant le superviseur
espace de noms. Un exemple est fourni ci-dessous.
serveur.superviseur.getState()
Vous pouvez obtenir une liste des méthodes prises en charge par le superviseur Interface XML-RPC en utilisant le
XML-RPC system.listMethods API:
serveur.system.listMethods()
Vous pouvez voir l'aide sur une méthode en utilisant le system.methodHelp API contre la méthode :
server.system.methodHelp('supervisor.shutdown')
Le manuel de formation superviseur L'interface XML-RPC prend également en charge le XML-RPC appels multiples API.
Vous pouvez prolonger superviseur fonctionnalité avec de nouvelles méthodes API XML-RPC en ajoutant de nouvelles
interfaces RPC de niveau supérieur si nécessaire. Voir rpcinterface_factories.
NOTE:
Tout appel de méthode XML-RPC peut entraîner une réponse d'erreur. Cela inclut les erreurs causées par
le client tels que de mauvais arguments, et toutes les erreurs qui font superviseur incapable d'
répondre à la demande. De nombreux programmes clients XML-RPC lèvent une exception lorsqu'une erreur
une réponse est rencontrée.
Statut et Contrôle
classe superviseur.rpcinterface.SupervisorNamespaceRPCInterface(supervisord)
getAPIVersion()
Renvoie la version de l'API RPC utilisée par Supervisord
ID de version de la chaîne @return
Cette API est versionnée séparément de Supervisor lui-même. La version API
retourné par obtenirAPIVersion ne change que lorsque l'API change. Son but
est d'aider le client à identifier avec quelle version de l'API Supervisor
c'est communiquer.
Lors de l'écriture d'un logiciel qui communique avec cette API, il est fortement
recommandé de tester d'abord la compatibilité de la version de l'API avant
faire des appels de méthode.
NOTE:
Le manuel de formation obtenirAPIVersion méthode remplace obtenirVersion trouvé dans le superviseur
versions antérieures à 3.0a1. Il est alias pour la compatibilité mais
getVersion() est obsolète et la prise en charge sera supprimée de
Superviseur dans une future version.
getSupervisorVersion()
Renvoie la version du package superviseur utilisée par superviseurd
ID de version de la chaîne @return
obtenirIdentification()
Renvoie la chaîne d'identification de superviseur
@return identifiant de chaîne identifiant la chaîne
Cette méthode permet au client d'identifier avec quelle instance Supervisor
il communique dans le cas d'environnements où plusieurs
Les superviseurs peuvent être en cours d'exécution.
L'identification est une chaîne qui doit être définie dans le
fichier de configuration. Cette méthode renvoie simplement cette valeur au
client.
obtenirÉtat()
Renvoie l'état actuel de superviseur en tant que struct
@return struct Une structure avec des clés int statecode, string statename
Il s'agit d'une valeur interne maintenue par le superviseur qui détermine ce que
Le superviseur pense être son état opérationnel actuel.
Certains appels de méthode peuvent modifier l'état actuel du superviseur. Pour
exemple, l'appel de la méthode superviseur.shutdown() pendant que la station est en
l'état RUNNING place le Superviseur dans l'état SHUTDOWN alors qu'il est
éteindre.
La méthode superviseur.getState() permet au client de vérifier
L'état du superviseur, tant à titre informatif que pour s'assurer que
les méthodes qu'il a l'intention d'appeler seront autorisées.
La valeur de retour est une structure :
{'code d'état' : 1,
'statename' : 'RUNNING'}
Les valeurs de retour possibles sont :
?? ??
│code d'état │ nom d'état │ Description │
?? ??
│2 │ FATAL │ Le superviseur a │
│ │ │ a vécu une grave │
│ │ erreur. ??
?? ??
│1 │ RUNNING │ Le superviseur travaille │
│ │ normalement. ??
?? ??
│0 │ REDÉMARRAGE │ Le superviseur est dans le │
│ │ │ processus de redémarrage. ??
?? ??
│-1 │ ARRÊT │ Le superviseur est dans le │
│ │ │ processus de fermeture │
│ │ vers le bas. ??
?? ??
Le manuel de formation MORTEL l'état signale des erreurs irrécupérables, telles que des erreurs internes
à l'intérieur des conditions d'emballement du superviseur ou du système. Une fois réglé sur MORTEL, la
Le superviseur ne peut jamais revenir à un autre état sans être redémarré.
Dans l' MORTEL state, toutes les méthodes futures à l'exception de superviseur.shutdown() et
superviseur.restart() échouera automatiquement sans être appelé et le
faute FATAL_STATE sera soulevé.
Dans l' Fermeture or RESTARTING états, tous les appels de méthode sont ignorés et
leurs valeurs de retour possibles ne sont pas définies.
obtenirPID()
Renvoie le PID du superviseur
@retour entier PID
readLog(décalage, longueur)
Lire les octets de longueur du journal principal à partir de l'offset
@param int offset offset à partir duquel commencer la lecture. @param int
longueur nombre d'octets à lire dans le journal. @chaîne de retour
résultat Octets du journal
Il peut soit renvoyer l'intégralité du journal, soit un certain nombre de caractères de la queue
du journal, ou une tranche du journal spécifiée par le décalage et la longueur
paramètres:
?? ??
│Offset │ Longueur │ Comportement de │
│ │ readProcessLog │
?? ??
│Négatif │ Pas zéro │ Mauvais arguments. Cela va
│ │ │ relever la faute │
│ │ MAUVAIS_ARGUMENTS. ??
?? ??
│Négatif │ Zéro │ Cela renverra le │
│ │ │ queue du journal, ou │
│ │ │ nombre de décalage de │
│ │ │ caractères de la fin │
│ │ du journal. Pour │
│ │ │ exemple, si compenser = -4
│ │ et longueur = 0, alors le
│ │ │ quatre derniers caractères │
│ │ │ sera retourné de │
│ │ │ la fin du journal. ??
?? ??
│Zéro ou Positif │ Négatif │ Mauvais arguments. Cela va
│ │ │ relever la faute │
│ │ MAUVAIS_ARGUMENTS. ??
?? ??
│Zéro ou Positif │ Zéro │ Tous les caractères seront │
│ │ │ est revenu du compenser │
│ │ │ spécifié. ??
?? ??
│Zéro ou Positif │ Positif │ Un certain nombre de caractères │
│ │ │ la longueur sera retournée │
│ │ de la compenser. ??
?? ??
Si le journal est vide et que l'intégralité du journal est demandée, une chaîne vide est
revenu.
Si le décalage ou la longueur est hors plage, le défaut MAUVAIS_ARGUMENTS vont
être retourné.
Si le journal ne peut pas être lu, cette méthode lèvera soit le PAS DE FICHIER
erreur si le fichier n'existe pas ou si le ÉCHEC erreur si autre problème
a été rencontré.
NOTE:
La méthode readLog() remplace readMainLog() trouvée dans Supervisor
versions antérieures à 2.1. Il est alias pour la compatibilité mais
readMainLog() est obsolète et la prise en charge sera supprimée de
Superviseur dans une future version.
clearLog()
Effacez le journal principal.
@return le résultat booléen renvoie toujours True sauf erreur
Si le journal ne peut pas être effacé car le fichier journal n'existe pas, le
faute PAS DE FICHIER sera élevé. Si le journal ne peut pas être effacé pour un autre
raison, la faute ÉCHEC sera soulevé.
fermer()
Arrêter le processus de supervision
@return le résultat booléen renvoie toujours True sauf erreur
Cette méthode arrête le démon Supervisor. Si des processus sont
en cours d'exécution, ils sont automatiquement tués sans avertissement.
Contrairement à la plupart des autres méthodes, si le superviseur est dans le MORTEL état, ce
méthode fonctionnera toujours.
redémarrage()
Redémarrer le processus du superviseur
@return le résultat booléen renvoie toujours True sauf erreur
Cette méthode redémarre en douceur le démon Supervisor. Si des processus sont
en cours d'exécution, ils sont automatiquement tués sans avertissement. Notez que le
le processus UNIX réel pour le superviseur ne peut pas redémarrer ; uniquement le principal du superviseur
boucle de programme. Cela a pour effet de réinitialiser les états internes de
Superviseur.
Contrairement à la plupart des autres méthodes, si le superviseur est dans le MORTEL état, ce
méthode fonctionnera toujours.
Processus Contrôle
classe superviseur.rpcinterface.SupervisorNamespaceRPCInterface(supervisord)
getProcessInfo(nom)
Obtenir des informations sur un processus nommé name
@param string name Le nom du processus (ou 'group:name') @return
struct result Une structure contenant des données sur le processus
La valeur de retour est une structure :
{'nom' : 'nom du processus',
'groupe' : 'nom du groupe',
« description » : « pid 18806, disponibilité 0:03:12 »
« démarrer » : 1200361776,
'arrêter' : 0,
« maintenant » : 1200361812,
« état » : 1,
'statename' : 'RUNNING',
'spawner': '',
'état de sortie' : 0,
'logfile' : '/path/to/stdout-log', # obsolète, b/c uniquement
'stdout_logfile' : '/chemin/vers/stdout-log',
'stderr_logfile' : '/chemin/vers/stderr-log',
'pid' : 1}
prénom Nom du processus
groupe Nom du groupe de processus
la description
Si l'état du processus est en cours d'exécution, la valeur de la description est process_id et
disponibilité. Exemple "pid 18806, disponibilité 0:03:12 ". Si l'état du processus est
la valeur de la description arrêtée est l'heure d'arrêt. Exemple : " 5 juin 03 h 16
".
Commencer Horodatage UNIX du démarrage du processus
Arrêtez Horodatage UNIX de la dernière fin du processus, ou 0 si le processus
n'a jamais été arrêté.
maintenant Horodatage UNIX de l'heure actuelle, qui peut être utilisé pour calculer
temps de fonctionnement du processus.
Etat Code d'état, voir process_states.
Nom d'état
Description de la chaîne de Etat, voir process_states.
fichier journal
Alias obsolète pour fichier_journal_stdout. Ceci est fourni uniquement pour
compatibilité avec les clients écrits pour Supervisor 2.x et peut être
supprimé à l'avenir. Utiliser fichier_journal_stdout à la place.
fichier_journal_stdout
Chemin absolu et nom de fichier vers le fichier journal STDOUT
fichier_journal stderr
Chemin absolu et nom de fichier vers le fichier journal STDOUT
géniteur
Description de l'erreur qui s'est produite lors du spawn, ou chaîne vide
si aucun.
état de sortie
État de sortie (niveau d'erreur) du processus, ou 0 si le processus est toujours
exécution.
Pid ID de processus UNIX (PID) du processus, ou 0 si le processus n'est pas
exécution.
getAllProcessInfo()
Obtenez des informations sur tous les processus
@return array result Un tableau des résultats de l'état du processus
Chaque élément contient une structure, et cette structure contient exactement la même
éléments comme la structure renvoyée par getProcessInfo. Si la table de processus
est vide, un tableau vide est renvoyé.
startProcess(nom, attendre = vrai)
Démarrer un processus
@param string name Nom du processus (ou nom de groupe, ou grouper:*) @param
boolean wait Attend que le processus soit complètement démarré @return boolean result
Toujours vrai sauf erreur
startAllProcesses (attendre = True)
Démarrer tous les processus répertoriés dans le fichier de configuration
@param boolean wait Attend que chaque processus soit complètement démarré @return
array result Un tableau de structs d'informations sur l'état du processus
startProcessGroup(nom, attendre = vrai)
Démarrez tous les processus du groupe nommé 'nom'
@param string name Le nom du groupe @param boolean wait Attendre
chaque processus doit être complètement démarré @return array result Un tableau de
structure d'informations sur l'état du processus
stopProcess(nom, attendre = vrai)
Arrêter un processus nommé par son nom
@param string name Le nom du processus à arrêter (ou 'group:name')
@param boolean wait Attendez que le processus soit complètement arrêté
@return boolean result Renvoie toujours True sauf erreur
stopProcessGroup(nom, attendre = vrai)
Arrêtez tous les processus du groupe de processus nommé « nom »
@param string name Le nom du groupe @param boolean wait Attendre
chaque processus doit être complètement arrêté @return array result Un tableau de
structure d'informations sur l'état du processus
stopAllProcesses (attendre = True)
Arrêter tous les processus dans la liste des processus
@param boolean wait Attend que chaque processus soit complètement arrêté @return
array result Un tableau de structs d'informations sur l'état du processus
sendProcessStdin(nom, caractères)
Envoyez une chaîne de caractères au stdin du nom du processus. Si non 7 bits
les données sont envoyées (unicode), elles sont encodées en utf-8 avant d'être envoyées au
processus' stdin. Si chars n'est pas une chaîne ou n'est pas unicode, augmentez
INCORRECT_PARAMETERS. Si le processus n'est pas en cours d'exécution, lancez NOT_RUNNING.
Si le processus stdin ne peut pas accepter l'entrée (par exemple, il a été fermé par le
processus enfant), levez NO_FILE.
@param string name Le nom du processus à envoyer (ou 'group:name')
@param string chars Les données de caractères à envoyer au processus
@return boolean result Renvoie toujours True sauf erreur
sendRemoteCommEvent(tapez, Les données)
Envoyer un événement qui sera reçu par les sous-processus de l'écouteur d'événement
l'abonnement à l'événement RemoteCommunication.
@param string type Chaîne pour la clé "type" dans l'en-tête de l'événement
@param string data Données pour le corps de l'événement @return booléen
Renvoie toujours True sauf erreur
rechargerConfig()
Recharger la configuration
@return le résultat booléen renvoie toujours True sauf erreur
addProcessGroup(nom)
Mettez à jour la configuration d'un processus en cours à partir du fichier de configuration.
@param string name nom du groupe de processus à ajouter @return booléen
résultat vrai en cas de succès
removeProcessGroup(nom)
Supprimez un processus arrêté de la configuration active.
@param string name nom du groupe de processus à supprimer @return
résultat booléen Indique si la suppression a réussi
Processus Journal
classe superviseur.rpcinterface.SupervisorNamespaceRPCInterface(supervisord)
readProcessStdoutLog(nom, décalage, longueur)
Lire les octets de longueur à partir du journal stdout du nom à partir de l'offset
@param string name le nom du processus (ou 'group:name')
@param int offset offset à partir duquel commencer la lecture. @param int
longueur nombre d'octets à lire dans le journal. @chaîne de retour
résultat Octets du journal
readProcessStderrLog(nom, décalage, longueur)
Lire les octets de longueur à partir du journal stderr du nom à partir de l'offset
@param string name le nom du processus (ou 'group:name')
@param int offset offset à partir duquel commencer la lecture. @param int
longueur nombre d'octets à lire dans le journal. @chaîne de retour
résultat Octets du journal
tailProcessStdoutLog(nom, décalage, longueur)
Fournit un moyen plus efficace de suivre le journal (stdout) que
readProcessStdoutLog(). Utilisez readProcessStdoutLog() pour lire des morceaux et
tailProcessStdoutLog() à la queue.
Requête (longueur) octets du journal de (nom), à partir de (décalage). Si
la taille totale du journal est supérieure à (offset + longueur), l'indicateur de débordement
est défini et le (offset) est automatiquement augmenté pour positionner le tampon
à la fin du journal. Si moins de (longueur) octets sont disponibles, le
le nombre maximum d'octets disponibles sera renvoyé. (offset) renvoyé est
toujours le dernier décalage dans le journal +1.
@param string name le nom du processus (ou 'group:name')
@param int offset offset pour commencer la lecture à partir de @param int length
nombre maximal d'octets à renvoyer @return array result [string
octets, décalage int, débordement booléen]
tailProcessStderrLog(nom, décalage, longueur)
Fournit un moyen plus efficace de suivre le journal (stderr) que
readProcessStderrLog(). Utilisez readProcessStderrLog() pour lire des morceaux et
tailProcessStderrLog() à la queue.
Requête (longueur) octets du journal de (nom), à partir de (décalage). Si
la taille totale du journal est supérieure à (offset + longueur), l'indicateur de débordement
est défini et le (offset) est automatiquement augmenté pour positionner le tampon
à la fin du journal. Si moins de (longueur) octets sont disponibles, le
le nombre maximum d'octets disponibles sera renvoyé. (offset) renvoyé est
toujours le dernier décalage dans le journal +1.
@param string name le nom du processus (ou 'group:name')
@param int offset offset pour commencer la lecture à partir de @param int length
nombre maximal d'octets à renvoyer @return array result [string
octets, décalage int, débordement booléen]
clearProcessLogs(nom)
Effacez les journaux stdout et stderr pour le processus nommé et rouvrez-les.
@param string name Le nom du processus (ou 'group:name') @return
résultat booléen Toujours vrai sauf erreur
clearAllProcessLogs()
Effacer tous les fichiers journaux de processus
@return array result Un tableau de structures d'informations sur l'état du processus
Système Méthodologie
classe superviseur.xmlrpc.SystemNamespaceRPCInterface(espaces de noms)
listeMethods()
Renvoie un tableau répertoriant les noms de méthodes disponibles
@return array result Un tableau de noms de méthodes disponibles (chaînes).
methodHelp(nom)
Retourne une chaîne montrant la documentation de la méthode
@param string name Le nom de la méthode. @return chaîne résultat Le
documentation pour le nom de la méthode.
methodSignature(nom)
Renvoie un tableau décrivant la signature de la méthode sous la forme [rtype,
ptype, ptype...] où rtype est le type de données de retour de la méthode, et
ptypes sont les types de données de paramètre que la méthode accepte dans la méthode
ordre des arguments.
@param string name Le nom de la méthode. @return résultat du tableau Le
résultat.
multiappel(appels)
Traiter un tableau d'appels et renvoyer un tableau de résultats. Les appels doivent
être des structures de la forme {'methodName': string, 'params': array}. Chaque
le résultat sera soit un tableau à un seul élément contenant la valeur du résultat, soit un
struct de la forme {'faultCode': int, 'faultString': string}. C'est
utile lorsque vous avez besoin de faire beaucoup de petits appels sans beaucoup de ronde
voyages.
@param array calls Un tableau de demandes d'appel @return array result An
tableau de résultats
PLUGINS
INDICES ET TABLES
· génindex
· indice mod
· chercher
Utiliser le superviseur en ligne à l'aide des services onworks.net
