J'essaie d'obtenir RabbitMQ-Server-2.4.0 en marche sur Centos 5.5 sur une instance Amazon AWS. P>
Mon instance utilise le noyau suivant: 2.6.18-Xenu-EC2-V1.2 P>
J'ai essayé l'installation d'Erlang et de RabbitMQ-Server en utilisant: 1) Yum Repos 2) Installation directe RPM 3) Compiler de la source. P>
Dans tous les cas, je reçois le message suivant lorsque vous essayez de démarrer la Processus Server rabbbitmq: P>
pthread / ethr_event.c: 98: erreur fatale en attente __ (): fonction non mis en œuvre (38) p>
Toute aide serait appréciée. P>
6 Réponses :
semble que ce noyau n'est pas compatible avec Erlang 14B, 14B01 ou 14B02 P>
Compiler Erlang 13B04 conduit à une installation réussie de RabbitMQ-Server P>
Compilation d'Erlang R14B03 (ERTS-5.8.4) fonctionne sur Centos 5.6 (finale) Virtualbox VM
Je l'ai installé en installant d'abord Erlang par Source: Après cela crée un lien symbolique pour également faire une ERL disponible pour l'utilisateur root: Installez RabbitMQ RPM (peut-être vérifier la dernière version de vous): P>
sudo ln -s / usr / local / bin / erl / bin / erl code> p>
wget http://www.rabbitmq.com/releases/rabbitmq-server/v2.4.1/rabbitmq-server-2.4.1-1.noarch.rpm
rpm -Uvh rabbitmq-server-2.4.1-1.noarch.rpm
Si Erlang est installé à partir de la source, l'installation RPM de Rabbitmq ne reconnaît pas Erlang indiquant que Erlang R12B-3 est requis.
Utilisation:
RPM --NODEPS -UVH RABBITMQ-SERVER-2.6.1-1.NOARCH.RPM P>
J'ai pu installer et utiliser Rabbitmq 2.6.1 avec succès sur Centos 5.6 avec Erlang R14B04 P>
Je doute que cela fonctionne. Vous ne le compilez pas avec Erlang. - Nodeps ne vérifie pas la dépendance et installez simplement le rabbbitmq. c'est faux.
J'ai essayé cette solution après avoir été recherchée pendant des heures dans Google et cela fonctionne. Parce que lorsque vous utilisez le RPM, il recherche un RPM Erlang qu'il ne trouvera pas lors de la compilation d'Erlang de la source
Pour les personnes à l'avenir, trouvez cette réponse, le site rabbbitmq a elle-même une réponse potentielle pour vous: P>
Installation sur Linux (Centos, Fedora, OpenSUSE, Redhat) basé sur RPM) < / p>
Erlang sur Rhel 5 (et Centos 5) P>
En raison de la stratégie de mise à jour de l'emballage EPEL, EPEL 5 contient une version Erlang R12B-5, qui est relativement vieux. Rabbitmq-Server prend en charge R12B-5, mais la performance peut être inférieure à celle des versions Erlang plus récentes, et Certaines fonctionnalités non essentielles ne sont pas prises en charge (support SSL, basé sur HTTP plug-ins y compris le plugin de gestion). Par conséquent, nous recommandons que Vous installez la version la plus récente d'Erlang. Le moyen le plus simple Pour ce faire, c'est utiliser un référentiel de packages fourni à cette fin par le propriétaire du paquet EPEL ERLANG. Activez-le en invoquant (en tant que root): p>
wget -o /etc/yum.repos.d/epel-erlang.repo http://repos.fedorapeople.org/repos/peter/erlang/epel -erlang.repo p>
puis installez ou mettez à jour Erlang avec Yum Installez Erlang. P> blockQuote>
Si vous descendez manuellement de la route du bâtiment Erlang sur une installation de système d'exploitation minimale, vous pouvez également constater que vous devez installer WXGTK & WXGTK-Devel afin que tous les tests de construction et de fonctionnement correctement. P>
Lors du démarrage erlang, le message Tentative de construire Erlang à partir de la source sur une boîte EC2 peut échouer de la même manière em> si la distribution installe des en-têtes de noyau dans / USR / Inclure / Linux comme une exigence d'autres packages. (E.G., Centos nécessite le package en-têtes du noyau comme une condition préalable aux en-têtes GCC, GCC-C ++, GLIBC-Devel et GLIBC, entre autres). Étant donné que les en-têtes installés par le paquet ne correspondent pas au noyau installé par les scripts de création d'images EC2, Erlang assume de manière incorrecte Futex_wait_private et Futex_wake_private sont disponibles. p> pour le corriger, le plus rapide est de corriger manuellement devrait devenir p> Si vous soupçonnez que le problème privé Futex est votre Problème, mais veulent le vérifier avant de recompiler tout Erlang, le programme suivant peut l'échéager:
p> coller dans Si votre noyau implémente des futex privés, vous verrez p> si vous avez un noyau sans fonctions de Fuex _private, vous verrez P> Pthread / Ethr_event.c: 98: Erreur fatale en attente __ (): Fonction non implémentée (38) code> est, sur les distributions modernes, la plus probable Le résultat d'une interaction binaire d'erlang précompilée avec un noyau qui ne met pas en œuvre futex_wait_private et futex_wake_private. Les noyaux Amazon fournit à EC2 ne mettent pas en œuvre ces macros futex_private_ p>
le correctif h2>
erts / include / interne / pthread / ethr_event.h code> pour utiliser le non-_private Mise en œuvre FUTEX:
p>
test rapide h2>
futextest.c code>, puis
gcc duttexte.C code> et
./.out code>. p>
FUTEX_WAKE SUCCESS
FUTEX WAIT SUCCESS
FUTEX_WAKE_PRIVATE HAD ERR 38: Function not implemented
FUTEX_WAIT_PRIVATE HAD ERR 38: Function not implemented