Aquí está el error que recibo:
ubuntu@sync1:/etc/puppet$ sudo /usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install rabbitmq-server
Reading package lists...
Building dependency tree...
Reading state information...
rabbitmq-server is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up rabbitmq-server (3.2.2-1) ...
* Starting message broker rabbitmq-server * FAILED - check /var/log/rabbitmq/startup_\{log, _err\}
[fail]
invoke-rc.d: initscript rabbitmq-server, action "start" failed.
dpkg: error processing rabbitmq-server (--configure):
subprocess installed post-installation script returned error exit status 1
E: Sub-process /usr/bin/dpkg returned an error code (1)
ubuntu@sync1:/etc/puppet$
Esto sucede después de ejecutar Sudo Puppet Apply Manifests/site.pp.
Aquí está mi clase de Conejo:
# See https://github.com/puppetlabs/puppetlabs-rabbitmq
class my_rabbitmq ($environment, $type, $user, $password) {
# case $environment {
# staging: {
# #@todo
# }
# production: {
# #@todo
# }
# }
#
# case $type {
# sync: {
# #@todo
# }
# async: {
# #@todo
# }
# }
class { '::rabbitmq':
delete_guest_user => true,
version => '3.2.2',
}->
rabbitmq_user { 'richard':
admin => true,
password => 'richard_password',
provider => 'rabbitmqctl',
}->
rabbitmq_user_permissions { 'richard@/':
configure_permission => '.*',
read_permission => '.*',
write_permission => '.*',
provider => 'rabbitmqctl',
}
}
Estoy probando esto en Ubuntu 12.04 LTS VM. ¿Algunas ideas? Esto me está volviendo loco, he estado atrapado durante horas tratando de resolver esto.
Respuesta1
También estoy teniendo este problema. La causa es que al instalar el paquete 'rabbitmq-server' en Ubuntu,Se inicia una instancia de Rabbitmq.. Esto es por diseño. Desafortunadamente.
En cuanto a una solución, todavía no la he encontrado.
Editar
No sé si este es tu caso, pero en mi caso, estaba cambiando el nombre del nodo en Puppet de 'conejo' a otra cosa.
La breve explicación es que, como mencioné, la instalación de Rabbitmq-server hace que se ejecute el servicio Rabbitmq-Server. De forma predeterminada, utiliza el nombre de nodo "conejo".
En mi caso, apareció Puppet, configuré Rabbitmq y luego, antes de intentar iniciar el servicio, ejecuté '/etc/init.d/rabbitmq-service status' para verificar y ver si ya se estaba ejecutando.
En un mundo ideal, la respuesta habría sido "sí", ya que, de hecho, se estaba ejecutando, pero en este caso, el script '/etc/init.d/rabbitmq-service' utiliza el nombre del nodo configurado para verificar y ver si la instancia se está ejecutando, y cuando Puppet cambió el nombre del nodo en /etc/rabbitmq/rabbitmq-env.conf, eso rompió por completo la capacidad del script de servicio para determinar si se estaba ejecutando, por lo que, por supuesto, el script devuelve 0, porque no puede encontrar una instancia en ejecución.
Luego, Puppet intenta iniciar la nueva instancia con el nuevo nombre de nodo, pero falla porque solo un servicio puede poseer un puerto a la vez, y la instancia en ejecución lo tenía.
Para solucionarlo, volví a configurar RABBITMQ_NODENAME en 'conejo' y todo funciona.
Escribí sobre esto aquí:
http://www.standalone-sysadmin.com/blog/2014/02/rabbitmq-on-ubuntu-via-puppet/
Respuesta2
http://blog.zugschlus.de/archives/974-Debians-Policy-rc.d-infrastructure-explained.html
Debian es frecuentemente criticado por este valor predeterminado, y la respuesta canónica es usar el marco de políticas entregado con sysv-rc para evitar que se inicien los servicios. Dado que este mecanismo a menudo se malinterpreta, escribo este artículo para generar más confusión sobre este asunto.
(publicación de blog no mía)