Hi,

currently /etc/init.d/mumble-server stop doesn't does not stop the murmurd
and "restart" spawns an additional instance of mumble-server, leading to
various problems. I'd assume "force-reload" is similarly affected.

This is caused by two separate issues:

First the init script specifies "--user $USER", where $USER is "root"
by default. But murmur will (by default) drop itself to "mumble-server"
user; so this flag prevents start-stop-daemon from finding the process.
Removing the --user switches resolves this part. I've included the modified
init-script below.

Second murmur does not write its own pidfile in the default setup.
I was able to fix this with
   chown root:mumble-server $PIDDIR && chmod g+w PIDDIR
This is a bit crude though and ideally murmurd would write its pidfile
_before_ dropping privileges instead if that's possible.
Apparently murmurd already does read ssl certificates before dropping
privileges.

There's also a related upstream issue, albeit apparently stale:
https://github.com/mumble-voip/mumble/issues/2388

~~ Nils

I must correct myself.

As I ofc only remembered after sending the bug report, I did already change
the initscript once before to start as root (so it can read the root-owned ssl
certs once on startup, before dropping privileges)

So in the default config, the --user switches shouldn't be a problem (but with
CAPABILITIES enabled they probably still are) and the pidfile-dir permission
should be the only problem.

~~ Nils

tags 980079 unreproducible moreinfo
thanks

Nils König:

I'd like to have some more information in order to figure out how I can help
with this issue.
------------
Is the system with this issue running systemd?
Which method of creating an SSL cert is being used?

I've tested mumble-server on Debian 10.7 for this, with the default
configuration, both with and without CAPABILITIES enabled, and I'm able to shut
down mumble-server correctly on a system running systemd.  The PID file is
/run/mumble-server/mumble-server.pid and it as well as the murmurd process
disappear when shutting it with with 'systemctl stop mumble-server'.

I understand the problem of needing to start as root in order to read ssl certs,
and I'm assuming this is in relation to creating an SSL cert with LetsEncrypt.
If so I think there's an alternative; I think the SSL cert can be copied with
different ownership + permissions to a location that mumble-server can access
using a "post-hook" or "deploy-hook" call to certbot or dehydrated (or copying
the file manually if making a self-signed SSL cert) to run a script that will
copy the cert(s) and alter file permissions in an automated way. I haven't
actually done this yet but that's the method I last intended to look into.

Mumble upstream also suggests a method of dealing with this by setting the
execute bit on directories in the folder path to get to the SSL certficate to
allow mumble-server to traverse the path and allow read the files. I think this
method is less restrictive and less secure though.

https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate


I'm fairly interested in trying to find a good solution to this, because this
permission problem is a common gripe that I hear from users on the Mumble IRC
channel, so if a better solution can be found maybe I could have upstream add it
to the wiki or the website so others could take advantage of it.

Sorry it took me so long to come back to this.
And also sorry for the lengthy reply.

Yes, the affected system does run systemd.

certbot (Let's Encrypt)
modification to the init-script I made months ago and forgot about was causing
this (I suspect it only started to cause problems after a reboot).
Sorry, for wasting your time by jumping to a report to quickly.

Though, I also already heard about about the same thing happening to another
user before (without any modification afaik). Hearing back from this user now,
the problem disappeared again for him without any apparent reason.
I'm afraid I don't know what's causing this issue for him and people
reporting this upstream. Again, I'm terribly sorry to not have better checked
on my side before reporting this.

Something (possibly related?) I noticed while investigating this:
If capabilities are used and uname in /etc/mumble-server.ini
is set to something else than "mumble-server", than this problem appears
as long as USER inside the init-script isn't also changed.
Ofc, before that happens murmur will first refuse to start at all, since
it will be unable to access vital files, like:
  /var/lib/mumble-server
  /var/log/mumble-server
  /etc/mumble-server.ini
Change ownership of those locations is perhaps more obvious than needing to
edit some variable inside the init-script. Especially since after changing
ownership of those files murmur will at first glance appear to start just fine
as no error about the missing pid file is printed.
I'm however neither sure if that really is the cause for those upstream
reports, nor what's the best way to solve this.


Now about the SSL-certs:

Using --post-hook would be cleaner than my current method of just chaining
certbot renewal and restarting/reloading affected services, like so:

  certbot renew --quiet && service mumble-server restart

If the certificate should remain root-only, then
  --post-hook 'service mumble-server restart'
seems ok to me and is comfortably short.

Otherwise, if making it accessible to mumble-server is acceptable I assume
calling a script similar to the following (!untested!) one in certbot's
post-hook would be better and allows to utilise a reload instead of restart:

  #!/bin/sh
  set -e
  umask 077
  mkdir -p /var/lib/mumble-server/ssl
  cp /etc/letsencrypt/live/mumble.example.org/fullchain.pem /var/lib/mumble-server/ssl
  cp /etc/letsencrypt/live/mumble.example.org/privkey.pem   /var/lib/mumble-server/ssl
  chown -R mumble-server:mumble-server /var/lib/mumble-server/ssl
  service mumble-server reload

Yes, I've seen this suggestion before, but didn't like it due to security
concerns and opted for starting murmur as root instead (which then drops root
privileges on its own).

~~ Nils

I ran into this issue last week on a brand-new install of Raspbian 'Bullseye' running on a RPi 3.  It essentially makes it impossible to control the daemon using normal systemd tools, and often results in multiple instances of murmurd running simultaneously.

All I did to run into it was install the OS, `apt upgrade` everything, install a handful of common packages (emacs-nox, screen, chrony; nothing exotic), then install mumble-server from the default Raspbian repos.

Both the 'start on boot' and 'high priority' dpkg configuration options were enabled.

I didn't install, nor am I trying to use, any custom SSL certs (or SSL certs at all, except as they might be used in the default configuration).

I encountered the problem almost immediately, because after `apt install mumble-server` completed, the first thing I did was lightly edit /etc/mumble-server.ini and then attempt to restart the service:

    # systemctl restart mumble-server.service
    <-- APPROX. 4 MINUTES PASS... -->
    Job for mumble-server.service failed because a timeout was exceeded.
    See "systemctl status mumble-server.service" and "journalctl -xe" for details.

The journal contains, among other things, these lines:

    mumble-server.service: Found left-over process 1469 (murmurd) in control
     group while starting unit. Ignoring.
    This usually indicates unclean termination of a previous run, or service
     implementation deficiencies.

And it appears there are now two instances of murmurd:

    # ps aux | grep murmurd
    mumble-+   650  0.0  2.4  78920 23324 ?        Sl   May28   0:06
     /usr/sbin/murmurd -ini /etc/mumble-server.ini
    mumble-+  5194  0.0  2.4  70700 23236 ?        S    May28   0:03
     /usr/sbin/murmurd -ini /etc/mumble-server.ini

And if I run `systemctl restart mumble-server` again, it will create a 3rd instance of murmurd and so on.

It's clear from reading about this issue that I'm not the first to run into it, and there appear to be a variety of solutions, but it's unclear what tradeoffs (if any) they involve.  It would really be ideal if the package just worked 'out of the box' with sane defaults.

Happy to provide additional information as needed.

V/R,
James