On 04/12/2015 06:37 PM, Erwan JACQ wrote: > I'm sorry but the systemd service file provided didn't change the > behavior. The issue is still the same on my machine.
Ugh. Okay. Thanks much for reporting this... at minimum it's good to know that a systemd service file likely isn't a fix for this. I have one last suggestion: in /etc/mumble-server.ini, try a setting of: host=0.0.0.0 This is the "any" interface and should therefore listen on any local IPs, regardless of what they are, and therefore regardless of whether the local IPs change. That's suggested at the bottom of: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ So as long as you want murmurd to listen to all local interfaces, this might be a good workaround. [I /thought/ murmurd started by listening to 0.0.0.0 by default, but my local testing seems to show it doesn't.] > Here are my tests with 2 configurations: > > A/with no "host" specified [...] Result looks like murmurd running but not listening to any IPs. > B/with "host" specified [...] <W>2015-04-13 00:12:21.203 1 => Server: TCP Listen on > 192.168.1.150:64738 failed: The address is not available > <W>2015-04-13 00:12:21.301 1 => Stopped murmurd then starts then quits because the network still isn't up. Ugh. Okay. > I've seen ssh uses 2 systemd files : "ssh.socket" and "ssh.service", > shouldn't mumble use also a ".socket"? I don't know how the ssh > systemd socket handle the fact the user can choose the SSH port is a > separate config file. See 'man systemd.socket'. These .socket files are for "socket-based activation", similar to starting services via inetd. In other words: systemd itself would listen on the port that murmurd would normally use, and would only start murmurd when the port was accessed -- but for this to work murmurd would have to have a way of accepting a socket passed to it, and I don't think it can do that currently. So I think what this would do would be to have systemd take the port murmurd would normally use, then it wouldn't be available for murmurd and it would likely quit with an error. If you decide to experiment with this, let me know if the above is what actually happens. > Thanks a lot for the help ! You're welcome. ;-) Thank you for yours. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
