Description of problem: When I tested rubygem-redis-namespace package, I faced this error. ``` + redis-server spec/test.conf redis-server: error while loading shared libraries: libjemalloc.so.2: cannot open shared object file: No such file or directory ``` I think redis needs jemalloc package as Requires. Version-Release number of selected component (if applicable): redis-4.0.9-1.fc29 How reproducible: Steps to Reproduce: 1. redis-server spec/test.conf redis-server: error while loading shared libraries: libjemalloc.so.2: cannot open shared object file: No such file or directory Actual results: Below message was shown. redis-server: error while loading shared libraries: libjemalloc.so.2: cannot open shared object file: No such file or directory Expected results: redis-server should be started. Additional info:
python-redis won't build from sources because of this.
$ rpm -qp --requires redis-4.0.10-1.fc29.x86_64.rpm | grep jemalloc libjemalloc.so.2()(64bit) $ rpm -qp --requires redis-4.0.9-1.fc29.x86_64.rpm | grep jemalloc libjemalloc.so.2()(64bit) This is not a bug in redis, but in 389-ds-base: $ dnf repoquery --disablerepo='*' --enablerepo='rawhide' --whatprovides 'libjemalloc.so.2()(64bit)' 389-ds-base-0:1.4.0.10-2.fc29.x86_64 389-ds-base-libs-0:1.4.0.10-2.fc29.x86_64 jemalloc-0:5.1.0-1.fc29.x86_64
This should now be fixed in 389-ds-base-1.4.0.11-1
389-ds-base-1.4.0.11-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b3f2f29e65
Thanks for the working! rubygem-redis-namespace on rawhide works now.
(In reply to Jun Aruga from comment #5) > Thanks for the working! > rubygem-redis-namespace on rawhide works now. No problem, sorry for the inconvenience.
389-ds-base-1.4.0.11-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b3f2f29e65
@Mark I have a few notes. * Why is the bundled jemalloc used on the first place? * Even after the change, there is still jemalloc referenced in -devel and -libs subpackages. Is the bundled jemalloc dynamically linked? Why? * Even though the bundling is not strictly prohibited as it used to be, you still should be using "Provides: bundled(<libname>) = <version>" [1]. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries
(In reply to Vít Ondruch from comment #8) > @Mark > > I have a few notes. > > * Why is the bundled jemalloc used on the first place? Because glibc memory allocator is awful in regards to the way we use memory in DS. We see massive RSS memory growth with glibc, but not with jemalloc (or tcmalloc). This has caused countless customer escalations. So we have no choice but to use jemalloc until the glibc allocator gets improved. There are bugs opened for this. > > * Even after the change, there is still jemalloc referenced in -devel and > -libs subpackages. Is the bundled jemalloc dynamically linked? Why? We are aware of this and are looking into it... > > * Even though the bundling is not strictly prohibited as it used to be, you > still should be using "Provides: bundled(<libname>) = <version>" [1]. We will look into this as well... > > [1] > https://fedoraproject.org/wiki/Packaging: > Guidelines#Bundling_and_Duplication_of_system_libraries Thanks for the pointer!
(In reply to mreynolds from comment #9) > (In reply to Vít Ondruch from comment #8) > > * Why is the bundled jemalloc used on the first place? > > Because glibc memory allocator is awful in regards to the way we use memory > in DS. We see massive RSS memory growth with glibc, but not with jemalloc > (or tcmalloc). This has caused countless customer escalations. > > So we have no choice but to use jemalloc until the glibc allocator gets > improved. There are bugs opened for this. My question was more about the "bundling".
389-ds-base-1.4.0.11-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a00a3e9b36
389-ds-base-1.4.0.11-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a00a3e9b36
389-ds-base-1.4.0.11-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.