Posts Tagged ‘sysadmin’

jemalloc-4.0.x for fedora and epel

Thursday, August 20th, 2015

jemalloc, Jason Evans’ general-purpose scalable concurrent malloc implementation, was recently updated to version 4.0.0. I have wrapped packages for Fedora, and will update rawhide in a few days. If you would like to test the packages already, have a look at

Update: Jason recently released updates through 4.0.1 to 4.0.3. Packages for 4.0.3 are pushed to rawhide. Builds for epel are available at

There are a few fedora packages that rely on jemalloc. If you have a chance to help testing, please recompile and test the package against the updated version. You can leave comments here, or send me a mail.

$ sudo repoquery --whatrequires jemalloc |\
  sed 's,\(.*\)-.*-.*,\1,g;' | sort | uniq | tr '\n' ' ' | fold -s; echo

blender blenderplayer bro gridengine gridengine-execd gridengine-qmaster 
gridengine-qmon jemalloc-devel nfs-ganesha nfs-ganesha-ceph nfs-ganesha-gluster 
nfs-ganesha-proxy nfs-ganesha-utils nfs-ganesha-vfs nfs-ganesha-xfs redis 

For those that would like to use jemalloc-4.0 on epel, I have built packages for epel 5, 6, and 7 as well. These will not be pushed to the official epel mirrors, as there are api and abi changes that make them binary incompatible with the existing packages in epel.

I have my happy day job at Redpill Linpro in Norway. Redpill Linpro is the market leader for professional Open Source and Free Software solutions in the Nordics, though we have customers from all over. For professional managed services, all the way from small web apps, to massive IPv4/IPv6 multi data center media hosting, and everything through container solutions, in-house, cloud, and data center, contact us at, or follow us on social media:

Today’s sysadmin tip: Finding what binaries to restart revisited

Monday, January 20th, 2014

Almost exactly two years ago, I posted a perl script to find what binaries to restart for Red Hat based systems. I digs a bit deeper than the excellent needs-restarting script that is provided by Red Hat, by running ldd on the running process binaries, and recursively checking all underlying libraries. I did an extra variant for Debian and derivates today.

Why is this necessary? Because processes may map libraries without opening them. If the underlying library is updated, needs-restarting (or checkrestart on Debian, Ubuntu and derivates) won’t list the process as need to be restarted. But the process may crash or behave strangely when it some time in the future opens a mapped library, and that library has been changed by an update.

And yes, this is a real problem, experienced on production systems.

Red Hat variant
Debian/Ubuntu variant