J'ai installé un nouveau serveur Ubuntu 10.04 et je me suis connecté en tant que root. J'ai installé haproxy avec apt-get.
Je peux exécuter haproxy directement en tant que démon, mais quand je fais /etc/init.d/haproxy start
rien ne se passe .. même pas un message d'erreur.
netstat -a
montre que rien n'utilise le port http que je tente d'équilibrer avec haproxy ...
Des idées?
Modifier
J'ai remarqué que apt-get install haproxy
dit ceci à la fin:
update-rc.d: avertissement: /etc/init.d/haproxy manquant dans les informations LSB update-rc.d: voir http://wiki.debian.org/LSBInitScripts
/etc/default/haproxy
dit ENABLED=1
Débogage de la sortie pour sh -xv /etc/init.d/haproxy start
#!/bin/sh
#
# chkconfig: - 85 15
# description: HA-Proxy is a TCP/HTTP reverse proxy which is particularly suited \
# for high availability environments.
# processname: haproxy
# config: /etc/haproxy.cfg
# pidfile: /var/run/haproxy.pid
# Source function library.
if [ -f /etc/init.d/functions ]; then
. /etc/init.d/functions
Elif [ -f /etc/rc.d/init.d/functions ] ; then
. /etc/rc.d/init.d/functions
else
exit 0
fi
+ [ -f /etc/init.d/functions ]
+ [ -f /etc/rc.d/init.d/functions ]
+ exit 0
root@li267-63:~#
Éditez /etc/default/haproxy
et assurez-vous qu’il contient une ligne qui dit ENABLED=1
.
La valeur par défaut est ENABLED = 0. Ceci est fait car haproxy n'a pas de configuration par défaut, donc vous devez d'abord le configurer, puis l'activer.
J'ai eu le même problème, où le réglage ENABLED n'avait aucun effet car la ligne "test" échouait toujours. Trouvé la raison: vous devez éditer /etc/default/haproxy
à la place du script init.
Je sais que ce fil d'un an .. mais juste essayer de partager ce que j'ai appris ..
utilisez /etc/init.d/haproxy reload
ou service haproxy reload
et il rechargera bien .. après tout, nous voulons juste que tout commence correctement;)
J'ai rencontré ce même problème après avoir d'abord installé le paquet maintenu par ubuntu, puis (après avoir réalisé que la version ne supportait pas la fonctionnalité dont j'avais besoin). Installation d'une version plus récente de hapaproxy ppa. Le script init.d avec lequel je me suis retrouvé a pointé sur/usr/sbin/haproxy alors que mon exécutable se trouvait dans/usr/local/sbin/haproxy. la sortie de débogage "sh -xv /etc/init.d/haproxy start" mentionnée précédemment a rendu ce problème assez évident.
J'ai le même problème. J'ai déjà défini ENABLED = 1, mais la configuration par défaut de update-rc.d semble être de mettre le haproxy dans K20 (rc0 | 1 | 6.d) et dans S20 (rc2 | 3 | 4 | 5.d). Ce qui signifie qu'il va essayer de démarrer avant la mise en réseau, donc dans mon cas, je reçois ceci dans le fichier boot.log: -
* Démarrage de haproxy haproxy [ALERT] 346/160552 (927): Démarrage du proxy haproxy: impossible de lier socket [ALERT] 346/160552 (927): Démarrage du proxy haproxy: impossible de lier socket [ALERT] 346/160552 (927): Démarrage du proxy haproxy: impossible de lier le socket [ALERT] 346/160552 (927): Démarrage du proxy haproxy: ne peut pas lier le socket [ALERT] 346/160552 (927): Démarrage du proxy haproxy: impossible de lier le socket [ALERT] 346/160552 (927): Démarrage du proxy haproxy: ne peut pas lier le socket [ALERT] 346/160552 (927) : Démarrage du proxy haproxy: impossible de lier le socket [Échec]
changer le numéro de démarrage en 35 semble résoudre le problème, mais je pense que 36 serait plus sûr (l'ancien numéro de réseau était de 35, il est donc préférable de le démarrer après cela). Alors essayez: -
update-rc.d -f haproxy supprimer update-rc.d haproxy start 35 2 3 4 5. arrêt 20 0 1 6.
Ensuite, redémarrez, et il devrait trier. Les mainteneurs de paquets auraient vraiment dû penser à cela.
Avez-vous essayé de le démarrer en tant que root ou avec sudo? Si vous êtes comme moi, vous oubliez parfois d’ajouter Sudo au début des commandes. J'ai essayé toutes vos commandes sans Sudo et elles ont échoué comme vous l'avez décrit. Cependant, avec Sudo devant eux, en utilisant un fichier par défaut haproxy.cfg
de l'installation, il s'exécute maintenant sans problème. Je pensais juste que je ferais remarquer que même avec les bonnes configurations, cela ne se passerait pas de Sudo.
Je viens de rencontrer le même problème avec le script haproxy init.d sur lucid. Je ne pouvais tout simplement pas démarrer haproxy, aussi j’ai cherché et trouvé que vous deviez changer la variable ENABLED dans le script /etc/init.d/haproxy.
Changer cette variable n'a cependant PAS aidé du tout et c'est pourquoi: Quelques lignes plus basses dans /etc/init.d/haproxy, la variable ENABLED est vérifiée par le script avec la ligne suivante: test "$ ENABLED"! = "0" || exit 0. J'ai remarqué que ce test échouerait TOUJOURS sur mon système, peu importe la valeur de ENABLED. Le reste du script n'est donc jamais exécuté.
Je dois avouer que je ne sais pas vraiment pourquoi cette ligne de test ne fonctionne pas correctement. Mais puisque nous voulons quand même que haproxy soit activé, pourquoi vérifier? ... En commentant cette ligne de test, ça a fonctionné pour moi.
J'espère que cela aide quelqu'un.
Couru dans le même problème sur Azure avec un vm de Debian. S'avère être assez simple. Le script init de haproxy utilise des dépendances d'exécution. Sur les anciens systèmes, update-rc.d était la solution, mais sur les systèmes plus récents, insserv est utilisé: https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
Donc, si vous avez utilisé update-rc.d pour ajouter le service haproxy sur des systèmes plus récents, procédez comme suit:
$ Sudo update-rc.d -f haproxy supprimer
$ Sudo insserv haproxy
J'ai aussi continué à regarder le scipt, je ne voyais pas pourquoi il ne fonctionnait pas malgré le ENABLED=1
défini dans le script init.
Finalement, après avoir un peu baissé les yeux, vous verrez que le /etc/default/haproxy-file
est généré juste avant le test, ce qui écrase la variable set dans le script init lui-même ...