☰

Mumble bindet sich beim Booten nicht an die Netzwerkadresse und muss neu gestartet werden (wartet nicht richtig auf das Netzwerk?)

tag-icon • tag-icon debian networking
Mumble bindet sich beim Booten nicht an die Netzwerkadresse und muss neu gestartet werden (wartet nicht richtig auf das Netzwerk?)

Ich habe eine unveränderte Standardinstallation des Mumble-Servers auf Debian Squeeze (Paket „mumble-server“). Bei einem früheren Setup funktionierte das Starten des Servers (genannt murmurd) beim Booten mit den Standard-Init-Skripten problemlos. Bei einem neuen Setup, das mir in jeder Hinsicht identisch erscheint, scheint murmurd beim Booten keine Verbindung zu einer Netzwerkadresse herzustellen. Daher können keine Clients eine Verbindung herstellen, bis ich den Prozess nach dem Booten neu starte.

Die Protokolle sind recht aufschlussreich. Beim Booten:

<W>2012-03-25 00:15:01.543 Murmur 1.2.2 (1.2.2-6+squeeze1) running on
X11: Debian GNU/Linux 6.0.4 (squeeze): Booting servers <W>2012-03-25
00:15:01.617 1 => Announcing server via bonjour <W>2012-03-25
00:15:01.650 1 => Not registering server as public

und es können keine Clients eine Verbindung herstellen. Die Verwendung von service mumble-server restartafter boot führt jedoch zu:

<W>2012-03-25 00:22:27.529 Murmur 1.2.2 (1.2.2-6+squeeze1) running on
X11: Debian GNU/Linux 6.0.4 (squeeze): Booting servers <W>2012-03-25
00:22:27.549 1 => Server listening on [::]:64738 <W>2012-03-25
00:22:27.559 1 => Announcing server via bonjour <W>2012-03-25
00:22:27.570 1 => Not registering server as public

Beachten Sie die dritte Zeile. Es scheint mir also, dass das Init-Skript versucht, den Daemon zu starten, bevor das Netzwerk läuft. Das /etc/rc2.d/S19mumble-servermit dem Paket mitgelieferte Skript sagt jedoch:

# Required-Start:       $network $local_fs $remote_fs dbus

Das exakt gleiche Setup funktioniert auf einer anderen Maschine (auf der ebenfalls Debian Squeeze läuft) einwandfrei, daher habe ich den Verdacht, dass es etwas mit der Zeitangabe beim Booten oder einem anderen nichtdeterministischen Faktor zu tun hat.

Ideen?

Antwort1

Ich weiß, dass diese Frage schon zwei Jahre alt ist, aber vor kurzem bin ich auf einem Rechner, auf dem „Wheezy“ läuft, über dasselbe Problem gestolpert. Nachdem ich auf verschiedenen Websites nach einer Lösung gesucht hatte, schien es sich um ein Problem zu handeln, das durch den Netzwerkmanager verursacht wurde, der die Netzwerkschnittstelle nicht schnell genug hochfuhr, damit Mumble seinen Socket öffnen konnte.

Daher habe ich den Netzwerk-Manager aus der Boot-Reihenfolge entfernt: update-rc.d network-manager remove und mein Netzwerk-Interface über die /etc/interfaces- und die /etc/resolv.conf-Datei wie beschrieben konfiguriert.Hier.

Das Hinzufügen des Netzwerk-Managers als Abhängigkeit im Init-Skript des Mumble-Servers /etc/init.d/mumble-serverund die Ausführung update-rc.d mumble-server remove && update-rc.d mumbleserver defaultshat leider nicht geklappt, obwohl Mumble einen höheren Sequenzwert (19; der Netzwerk-Manager hatte 18) erhielt.

verwandte Informationen