Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#980079: mumble-server: service restart and stop borked
74 views
Skip to first unread message
Nils König
Jan 14, 2021, 2:00:03 AM1/14/21
to
Package: mumble-server
Version: 1.3.0~git20190125.440b173+dfsg-2
Severity: normal
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
-- System Information:
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Architecture: armv7l
Kernel: Linux 5.4.83-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mumble-server depends on:
ii adduser 3.118
ii debconf [debconf-2.0] 1.5.71
ii libatomic1 8.3.0-6+rpi1
ii libavahi-client3 0.7-4+b1
ii libavahi-common3 0.7-4+b1
ii libavahi-compat-libdnssd1 0.7-4+b1
ii libc6 2.28-10+rpi1
ii libcap2 1:2.25-2
ii libgcc1 1:8.3.0-6+rpi1
ii libprotobuf17 3.6.1.3-2+rpi1
ii libqt5core5a 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5dbus5 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5network5 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5sql5 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5sql5-sqlite 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5xml5 5.11.3+dfsg1-1+rpi1+deb10u4
ii libssl1.1 1.1.1d-0+deb10u4+rpt1
ii libstdc++6 8.3.0-6+rpi1
ii libzeroc-ice3.7 3.7.2-4
ii lsb-base 10.2019051400+rpi1
mumble-server recommends no packages.
mumble-server suggests no packages.
-- Configuration Files:
/etc/init.d/mumble-server changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=mumble-server
DESC="Mumble VoIP Server"
PIDDIR=/run/$NAME
PIDFILE=$PIDDIR/$NAME.pid
DAEMON=/usr/sbin/murmurd
#USER=mumble-server
# mumble will drop to 'mumble-server' itself
USER=root
GROUP=mumble-server
test -x $DAEMON || exit 0
INIFILE=/etc/mumble-server.ini
DAEMON_OPTS="-ini $INIFILE"
MURMUR_USE_CAPABILITIES=0
MURMUR_LIMIT_NOFILE=0
if [ -f /etc/default/$NAME ] ; then
. /etc/default/$NAME
fi
. /lib/init/vars.sh
. /lib/lsb/init-functions
if [ "$MURMUR_LIMIT_NOFILE" -gt 0 ] ; then
ulimit -n $MURMUR_LIMIT_NOFILE
fi
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
[ -d $PIDDIR ] || install -o $USER -d $PIDDIR
if [ "$MURMUR_USE_CAPABILITIES" != "1" ] ; then
start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--chuid $USER:$GROUP \
--exec $DAEMON \
-- $DAEMON_OPTS
else
start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--exec $DAEMON \
-- $DAEMON_OPTS
fi
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
start-stop-daemon --stop --quiet \
--retry=TERM/30/KILL/5 \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
case "$?" in
0|1) rm -f $PIDFILE
[ "$VERBOSE" != no ] && log_end_msg 0
;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
if start-stop-daemon --test --stop --quiet \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
then
[ "$VERBOSE" != no ] && echo "$DESC is running."
exit 0
else
[ "$VERBOSE" != no ] && echo "$DESC is not running"
exit 3
fi
;;
force-reload)
#--user $USER \
start-stop-daemon --stop --test --quiet \
--pidfile $PIDFILE \
--exec $DAEMON \
&& $0 restart || exit 0
;;
restart)
[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$NAME"
start-stop-daemon --stop --quiet \
--retry=TERM/30/KILL/5 \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
case "$?" in
0|1)
[ -d $PIDDIR ] || install -o $USER -d $PIDDIR
rm -f $PIDFILE
if [ "$MURMUR_USE_CAPABILITIES" != "1" ] ; then
start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--chuid $USER:$GROUP \
--exec $DAEMON \
-- $DAEMON_OPTS
else
start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--exec $DAEMON \
-- $DAEMON_OPTS
fi
case "$?" in
0) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
*) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
*)
[ "$VERBOSE" != no ] && log_end_msg 0
;;
esac
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|force-reload}" >&2
exit 3
;;
esac
exit 0
-- debconf information:
mumble-server/start_daemon: true
mumble-server/use_capabilities: false
Version: 1.3.0~git20190125.440b173+dfsg-2
Severity: normal
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
-- System Information:
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Architecture: armv7l
Kernel: Linux 5.4.83-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mumble-server depends on:
ii adduser 3.118
ii debconf [debconf-2.0] 1.5.71
ii libatomic1 8.3.0-6+rpi1
ii libavahi-client3 0.7-4+b1
ii libavahi-common3 0.7-4+b1
ii libavahi-compat-libdnssd1 0.7-4+b1
ii libc6 2.28-10+rpi1
ii libcap2 1:2.25-2
ii libgcc1 1:8.3.0-6+rpi1
ii libprotobuf17 3.6.1.3-2+rpi1
ii libqt5core5a 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5dbus5 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5network5 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5sql5 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5sql5-sqlite 5.11.3+dfsg1-1+rpi1+deb10u4
ii libqt5xml5 5.11.3+dfsg1-1+rpi1+deb10u4
ii libssl1.1 1.1.1d-0+deb10u4+rpt1
ii libstdc++6 8.3.0-6+rpi1
ii libzeroc-ice3.7 3.7.2-4
ii lsb-base 10.2019051400+rpi1
mumble-server recommends no packages.
mumble-server suggests no packages.
-- Configuration Files:
/etc/init.d/mumble-server changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=mumble-server
DESC="Mumble VoIP Server"
PIDDIR=/run/$NAME
PIDFILE=$PIDDIR/$NAME.pid
DAEMON=/usr/sbin/murmurd
#USER=mumble-server
# mumble will drop to 'mumble-server' itself
USER=root
GROUP=mumble-server
test -x $DAEMON || exit 0
INIFILE=/etc/mumble-server.ini
DAEMON_OPTS="-ini $INIFILE"
MURMUR_USE_CAPABILITIES=0
MURMUR_LIMIT_NOFILE=0
if [ -f /etc/default/$NAME ] ; then
. /etc/default/$NAME
fi
. /lib/init/vars.sh
. /lib/lsb/init-functions
if [ "$MURMUR_LIMIT_NOFILE" -gt 0 ] ; then
ulimit -n $MURMUR_LIMIT_NOFILE
fi
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
[ -d $PIDDIR ] || install -o $USER -d $PIDDIR
if [ "$MURMUR_USE_CAPABILITIES" != "1" ] ; then
start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--chuid $USER:$GROUP \
--exec $DAEMON \
-- $DAEMON_OPTS
else
start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--exec $DAEMON \
-- $DAEMON_OPTS
fi
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
start-stop-daemon --stop --quiet \
--retry=TERM/30/KILL/5 \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
case "$?" in
0|1) rm -f $PIDFILE
[ "$VERBOSE" != no ] && log_end_msg 0
;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
if start-stop-daemon --test --stop --quiet \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
then
[ "$VERBOSE" != no ] && echo "$DESC is running."
exit 0
else
[ "$VERBOSE" != no ] && echo "$DESC is not running"
exit 3
fi
;;
force-reload)
#--user $USER \
start-stop-daemon --stop --test --quiet \
--pidfile $PIDFILE \
--exec $DAEMON \
&& $0 restart || exit 0
;;
restart)
[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$NAME"
start-stop-daemon --stop --quiet \
--retry=TERM/30/KILL/5 \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
case "$?" in
0|1)
[ -d $PIDDIR ] || install -o $USER -d $PIDDIR
rm -f $PIDFILE
if [ "$MURMUR_USE_CAPABILITIES" != "1" ] ; then
start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--chuid $USER:$GROUP \
--exec $DAEMON \
-- $DAEMON_OPTS
else
start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--exec $DAEMON \
-- $DAEMON_OPTS
fi
case "$?" in
0) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
*) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
*)
[ "$VERBOSE" != no ] && log_end_msg 0
;;
esac
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|force-reload}" >&2
exit 3
;;
esac
exit 0
-- debconf information:
mumble-server/start_daemon: true
mumble-server/use_capabilities: false
Nils König
Jan 14, 2021, 2:20:04 AM1/14/21
to
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
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
Chris Knadle
Jan 15, 2021, 5:10:03 AM1/15/21
to
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.
-- Chris
--
Chris Knadle
Chris....@coredump.us
thanks
Nils König:
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.
-- Chris
--
Chris Knadle
Chris....@coredump.us
Nils König
Jan 27, 2021, 7:20:03 PM1/27/21
to
Sorry it took me so long to come back to this.
And also sorry for the lengthy reply.
On Fri, Jan 15, 2021 at 09:27:30 +0000, Chris Knadle wrote:
> Is the system with this issue running systemd?
Yes, the affected system does run systemd.
> Which method of creating an SSL cert is being used?
certbot (Let's Encrypt)
> 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. […]
Welp, I couldn't reproduce it on other systems either; turned out some
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:
> I understand the problem of needing to start as root in order to read ssl
> certs, and […] I think there's an alternative; I think the SSL cert can
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
> Mumble upstream also suggests […]
> https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate
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).
> 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.
>
> -- Chris
~~ Nils
And also sorry for the lengthy reply.
On Fri, Jan 15, 2021 at 09:27:30 +0000, Chris Knadle wrote:
> 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
Welp, I couldn't reproduce it on other systems either; turned out some
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:
> I understand the problem of needing to start as root in order to read ssl
> 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 […]
> mumble-server can access using a "post-hook" or "deploy-hook" call to
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
> Mumble upstream also suggests […]
> https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate
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).
> 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.
>
> -- Chris
James Tuttle
May 29, 2023, 1:00:06 AM5/29/23
to
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
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
0 new messages