Bug #3446

[mumble-server]: not working after Migration from Murmur

ryry - about 1 year ago - . Updated 5 months ago.

% Done:



  • steps to reproduce:

1. Using a working install of murmur upgrade via the usual pacman -Syu and say yes/y to the replacement of the package murmur with mumble server.

2. As requested consolidate the relevant config into the from the murmur.ini to the mumble-server.ini, then copy or move the /var/db/murmur/murmur.sqlite file to /var/lib/mumble-server/mumble-server.sqlite and make sure that the _mumble-server system user is able to access the ssl certs.

3. Start mumble using either the systemd unit or the mumble-server -fg -in ... (etc) command, both continue fine until it reads the following:

Feb 09 20:05:52 hostname mumble-server[3783]: mumble-server: /build/mumble/src/mumble-1.5.517/src/MumbleProtocol.cpp:370:
void Mumble::Protocol::UDP>AudioEncoder<role>::preparePreEncodedSnippets() [with Mumble::Protocol::Role role = Mumble::Protocol::Role::Server]:
Assertion `successful' failed.

Whilst systemd shows the mumble-server unit as active, the server is not responsive or seemingly operational and top shows fairly high cpu usage (perhaps looping?).

Downgrading back to murmur fixes the issue



Updated by bill-auger about 1 year ago

  • Description updated (diff)

Updated by bill-auger about 1 year ago

  • Description updated (diff)

Updated by ryry 12 months ago

Any ideas on what to do about this? Should I report it upstream to arch somehow? I found this on the archlinuxarm forum (last post), suggesting that there was a same or similar issue with the mumble client package , but no issues mentioned on offical bug trackers etc . I did manage to downgrade back to a working murmur, but in doing so you have to also downgrade grpc and two/three of its dependencies (grpc looks like its no longer part of the mumble build post after the 1.5 release).

Many Thanks


Updated by ryry 9 months ago

There was a recent rebuild of this package with a newer protobuf package, but this still doesn't seem to have rectified the issue. No sign of any upstream bug reports either.

Many thanks


Updated by ryry 6 months ago

This bug now has an open issue on the mumble GitHub

However, its mentioned in the response to the issue that when building, release mode is used to disable assertions (which appears to be a potential cause of the failure), but when looking at the upstream arch cmake uses none for release type, rather than release or debug, so not sure if there is something there which is different, older pre 1.5 versions seem to specify the same, and worked in the past, but just wondered if this could play a factor in its continued state of broken, but that which only seems to be reported by parabola or arch users?

Many Thanks


Updated by bill-auger 6 months ago

  • Subject changed from Murmur > Mumble-server Migration to [mumble-server]: not working after Migration from Murmur

just to avoid ignoring the issue entirely, i will state that this is an arch package - the best way to handle it is to verify that the bug exists in arch, then report the bug to arch - parabola really should not do anything about it unless the bug is not present in arch or unless arch neglects or refuses to fix it

the main difference i can see is that the server should not be started as root anymore; but only by the dedicated 'mumble' user

there is no bug report about this on the arch bug tracker; so it is not actually "reported by arch users" - if arch users are reporting the bug to the upstream, they are reporting the bug to the wrong people - if i felt like signing into github now, i would add that to the upstream ticket - it is selfish to report bugs in distro packages to the upstream; because even if the problem is solved, it is solved for only one person, yet remains for possibly all other users of the distro

from the upstream perspective, the upstream should have no interest in a bug in a any distro package, unless the bug can be reproduced from source, which that OP has not demonstrated - if the bug is in arch, and if arch users would report the bug to arch, then the arch maintainer would be more likely to know about it and fix it - in that usual case, all arch and parabola users would get the fix automatically

from parabola's perspective, this ticket would normally be marked as 'forwarded-upstream'; but that would not be very useful or accurate in this case - as it is now, we do not know if the bug is present in arch, or if the archg packager is aware of it - that github bug report has gone stale and will probably never be fixed; because the upstream is not obligated to fix bugs in distro packages

as a last resort, there is the 'umurmur' server - you could probably use that until this is resolved


Updated by ryry 5 months ago

I appreciate (as above) bill-auger noted that this is an upstream (archlinux arm) package, however I feel this is useful info, I have tried the same setup today using x86 and it works, there is no error as with the same package(s) than when using it on arm hardware, the server works fine as expected, this may suggest why there are no reports to upstream arch as there isn't a problem there considering its been non functional for best part of 2023. I wonder if this is connected to the outdated glibc package as that is both a dependency of protobuf and mumble-server as this is up to date in x86.

As you mentioned, bill-auger, The fact that its reported to the mumble devs is probably not going to change anything as its appears a problem now only specific to archlinux arm users and again as you mentioned in your last response, archlinuxarm seems to have no way of communicating these bugs in a way to raise them with anyone who can address this, despite people raising the issues on the forums there, there is no responses given in most cases. My best guess is that, if the glibc or any other outdated dependency related to it is updated to mirror the upstream arch, then the mumble-server package may well work again.


Updated by bill-auger 5 months ago

i just installed mumble-server for ARM and it works as expected - your problem must be related to the migration; but only someone in that situation could troubleshoot it - i can not even verify if this is a bug for everyone or if it affects only you

i would try a clean install with the default config file and a new database - note that it gave this advice when installing:

>>> This package replaces murmur!
    Stop murmur.service, move /var/db/murmur/murmur.sqlite
    to /var/lib/mumble-server/mumble-server.sqlite and
    consolidate /etc/murmur.ini with /etc/mumble/mumble-server.ini.
    When starting with a new database, create a superuser password
    before starting mumble-server.service, by running the following
    as the _mumble-server user:
    mumble-server -ini /etc/mumble/mumble-server.ini -supw <password>

so that initial command is like this:

sudo -u _mumble-server mumble-server -ini /etc/mumble/mumble-server.ini -supw PASSWORD

Updated by ryry 5 months ago

I had tried the above suggestions before with no luck and I still get the same error now even after a fresh install and new database. So not sure whats different for you than me which makes it works?


Updated by ryry 5 months ago

I have tried this on a separate arm device, this same error occurs there to, so I am not sure that it has anything to do with my migration or config. Also, there has been reports by other users to the mumble devs as mentioned before, Bill-auger, Where you able to connect to the server itself after you where running? As systemd will show it as running, but its actually just looping the core dump and intialising again, then failing (well for me at least).


Updated by bill-auger 5 months ago

no, i did not try to connect


Updated by bill-auger 5 months ago

i confirmed the original problem as described - systemd happily shows the service as running; but in reality, it only dumps core and restarts continuously

i tried starting it as unprivileged user via; but it does the same - so i think we can rule out systemd and a user/permissions problem - it may be a real problem with protobuf v23 on ARM

this patch in the PKGBUILD looked intere4sting; so i had the idea to try compiling against the previous protobuf (v21), as the upstream's suggested C14

  # protobuf 23 requires C++17
  sed -e 's|CMAKE_CXX_STANDARD 14|CMAKE_CXX_STANDARD 17|' -i $pkgname-$pkgver/CMakeLists.txt

but it failed to compile - cmake and/or pkgconf fails to find openssl

|  CMake Error at cmake/pkg-utils.cmake:87 (message):
|    OpenSSL component not found: Crypto

however, i just noticed that the bug report against archarm is from Apr 01, 2023 - the rename of the server package, storage, and user was on Jan 31 - v21 was the current version at that time; so i probably should have tried an even earlier version


Updated by bill-auger 5 months ago

  • Status changed from unconfirmed to confirmed

Updated by ryry 5 months ago

bill-auger wrote:

i confirmed the original problem as described - systemd happily shows the service as running; but in reality, it only dumps core and restarts continuously

i had the idea to try compiling against the previous protobuf; but it failed to compile - cmake and/or pkgconf fails to find openssl


Thanks bill-auger for confirming the issue and trying to compile against the earlier protobuf. As previously mentioned, I wonder, if, As the only packages that both mumble-server and protobuf where both dependent but to which haven't been updated for arch arm appear to be glibc, my thoughts (though it is only supposition) was that this is playing a roll somewhere in this issue, given that the glibc package for arch has been since this issue began and the mumble-server package works on x86, it allows you to connect and use the server. It appears the glibc issue has been raised on the forums, but no response, and this package is last update was May 2022, unlike arch x86 which was updated between then and now and latest update was last month (October 2023). That would explain perhaps, the length of this issue, 9+ months and arm specificity. I suppose we won't know unless or if glibc in arch arm or unless the arch arm people respond to the forum posts or unless anyone can shed some light on if this could be the actual cause.

I presume that given glibc is a/part of a toolchain package, it wouldn't be possible for me to compile glibc (as per the latest x86 build and then compile mumble-server using this, as glibc is so tightly woven to many other packages on my system of which would each require a rebuild?


Updated by bill-auger 5 months ago

fine idea - if glibc is the problem, a simple rebuild should fix it - have you
tried rebuilding the mumble package? - i only tried once; but it would not
compile for me


Updated by ryry 5 months ago

I have not no, not yet at least. Though I am tempted to try building it first with the current settings in the PKGBUILD and current protobuf, however but changing the flag "-DCMAKE_BUILD_TYPE=NONE" (which the arch/archarm PKGBUILDS use) to "-DCMAKE_BUILD_TYPE=Release" as mentioned here, as apparently the dev in question disables assertions anyway (an list this as a potential reason they haven't seen it), which may or might not remove the issue of it core dumping due to this, which while glibc may or may not be the cause, assertions may not be relevant/required to/for a usable build?.

Also available in: Atom PDF