web-dev-qa-db-fra.com

Superviseur sur Debian Wheezy: un autre programme écoute déjà sur un port que l'un de nos serveurs HTTP est configuré pour utiliser

Quand je lance service supervisor start Je rencontre l'erreur suivante:

Starting supervisor: Error: Another program is already listening on a port that one of our HTTP servers is configured to use.  Shut this program down first before starting supervisord.
For help, use /usr/bin/supervisord -h

Contenu de / var/log/superuser/supervisord.log:

2014-08-04 16:25:45,891 CRIT Supervisor running as root (no user in config file)
2014-08-04 16:25:45,891 WARN Included extra file "/etc/supervisor/conf.d/com.domain.subdomain.conf" during parsing

Bon à savoir:
- J'utilise Debian Wheezy sur un serveur Digital Ocean.
- J'ai essayé de vérifier les ports utilisés par le superviseur dans une boîte Vagrant propre avec les mêmes spécifications, mais j'ai les mêmes erreurs.

Comment puis-je vérifier quel port est à l'origine de cette erreur?

debiansupervisord
42
balintant

J'ai résolu mon problème en dissociant le .sock fichier.

Sudo unlink /var/run/supervisor.sock

Si cela ne vous aide pas, vous devez vérifier et dissocier le fichier à /tmp/supervisor.sock.

56
balintant

Tapez ceci dans votre terminal

ps -ef | grep supervisord

Vous obtiendrez un pid de supervord comme ceux-ci

root   2503  1  0 Nov19 ?  00:03:23 /usr/bin/python /usr/bin/supervisord
root   21337 2556  0 18:15 pts/8   00:00:00 grep --color=auto supervisord

Et le PID est 2503

Tapez ensuite ceci:

kill -s SIGTERM 2503

Ça devrait marcher

42
N'faly Kaba

Ma situation était un peu spécifique, mais cela peut quand même être utile.

J'exécutais quelques conteneurs Docker sur le même hôte. Tous les conteneurs fonctionnaient en mode de mise en réseau hôte . Chaque conteneur avait plusieurs processus contrôlés par le superviseur.

Le premier conteneur arrivait toujours et tous les autres échouaient avec l'avertissement que l'OP mentionnait: Another program is already listening on a port that one of our HTTP servers is configured to use. Shut this program down first before starting supervisord.

Pour moi, le problème était que j'avais la ligne suivante dans ma configuration de superviseur:

[inet_http_server]
port=127.0.0.1:9001

[supervisorctl]

Le premier conteneur réussirait à se lier au port 9001 et chaque conteneur suivant ne démarrerait pas car ils essaieraient également de se lier à ce même port, qui était déjà pris.

J'ai remplacé ces lignes par ce qui suit, en passant d'une liaison de serveur http sur localhost: 9001 à un serveur fonctionnant sur une socket de domaine unix.

[unix_http_server]
file=/var/run/supervisor.sock

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock

Cela a corrigé les collisions portuaires et tous les conteneurs ont pu démarrer.

6
turtlemonvh

Semblable à la réponse de @ N'falyKaba mais peut-être un peu plus direct, à partir des nouvelles versions de Supervisor, vous pouvez utiliser supervisorctl pid pour obtenir le pid, le tuer et redémarrer:

$ kill -s SIGTERM $(supervisorctl pid)

Recommencer:

$ supervisord -c /path/to/supervisord.conf

Source: documents .

4
Brad Solomon

Eu le même problème ici. La solution était que systemctl stop supervisor.service n'a pas arrêté le service. supervord est peut-être toujours en cours d'exécution bien que vous pensiez le contraire.

Assurez-vous d'avoir essayé avant de dissocier manuellement le socket.

J'ai souvent rencontré des problèmes pour faire /etc/init.d/supervisor restart bien que /etc/init.d/supervisor stop && /etc/init.d/supervisor start travaux.

3
karlsebal