Hier ist der Fehler, den ich bekomme:
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$
Dies geschieht, nachdem ich sudo puppet apply manifests/site.pp ausgeführt habe.
Hier ist meine Rabbit-Klasse:
# 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',
}
}
Ich versuche dies auf einer Ubuntu 12.04 LTS VM. Irgendwelche Ideen? Das macht mich verrückt, ich stecke schon seit Stunden fest und versuche, das herauszufinden.
Antwort1
Ich habe auch dieses Problem. Die Ursache ist, dass bei der Installation des Pakets „rabbitmq-server“ unter Ubuntueine Instanz von rabbitmq wird gestartet. Das ist Absicht. Traurigerweise.
Was eine Lösung betrifft, habe ich noch keine gefunden.
Bearbeiten
Ich weiß nicht, ob dies bei Ihnen der Fall ist, aber in meinem Fall habe ich den Knotennamen in Puppet von „Rabbit“ in etwas anderes geändert.
Die kurze Erklärung ist, dass, wie erwähnt, die Installation von rabbitmq-server dazu führt, dass der rabbitmq-server-Dienst ausgeführt wird. Standardmäßig wird der Knotenname „rabbit“ verwendet.
In meinem Fall kam Puppet zum Einsatz, konfigurierte rabbitmq und führte dann, bevor ich versuchte, den Dienst zu starten, „/etc/init.d/rabbitmq-service status“ aus, um zu prüfen, ob es bereits ausgeführt wurde.
In einer idealen Welt wäre die Antwort „Ja“ gewesen, da es tatsächlich ausgeführt wurde. In diesem Fall verwendet das Skript „/etc/init.d/rabbitmq-service“ jedoch den konfigurierten Knotennamen, um zu prüfen, ob die Instanz ausgeführt wird. Als Puppet den Knotennamen in /etc/rabbitmq/rabbitmq-env.conf änderte, konnte das Serviceskript nicht mehr feststellen, ob es ausgeführt wurde. Daher gibt das Skript natürlich 0 zurück, da es keine laufende Instanz finden kann.
Puppet versucht dann, die neue Instanz mit dem neuen Knotennamen zu starten. Dies schlägt jedoch fehl, da immer nur ein Dienst einen Port besitzen kann und die laufende Instanz diesen hatte.
Um das Problem zu beheben, habe ich RABBITMQ_NODENAME wieder auf „Rabbit“ gesetzt und alles funktioniert.
Ich habe hier darüber geschrieben:
http://www.standalone-sysadmin.com/blog/2014/02/rabbitmq-on-ubuntu-via-puppet/
Antwort2
http://blog.zugschlus.de/archives/974-Debians-Policy-rc.d-infrastructure-explained.html
Debian wird häufig für diesen Standard kritisiert und die kanonische Antwort besteht darin, das mit sysv-rc gelieferte Richtlinien-Framework zu verwenden, um den Start von Diensten zu verhindern. Da dieser Mechanismus häufig missverstanden wird, schreibe ich diesen Artikel, um noch mehr Verwirrung in diese Angelegenheit zu stiften.
(Blogbeitrag nicht von mir)