Upstart and resolvconf cache

I’ve recently found this when I was trying to fix a nameserver config issue with resolvconf on Ubuntu. When resolvconf populates /etc/resolv.conf, it will read what we have configured in /etc/resolvconf/resolv.conf.d (head, base, tail, etc) and also any dns-server declared in /etc/network/interfaces. I had a conflict with something I was populating in the head file (with Puppet) from something that was configured under /etc/network/interfaces. So I removed the conflicting dns-server declaration from the interfaces file and run “resolvconf -u” to update the config. To my surprise, the “deleted” nameservers from /etc/network/interfaces were still included in /etc/resolv.conf. After some debugging, I have noticed that resolvconf’s Upstart script now keeps a cache file under /run/resolvconf/interface that is a copy of the previous /etc/network/interfaces. You need to delete this file and restart resolvconf to make it work: “stop resolvconf ; start resolvconf”. ->

Not long ago I decided to move to a new personal domain and registered I am in the process of moving everything from to my new domain, which will cease to exist in a few months.  If you are one of the brave souls still keeping an eye on my feed, I advise to change to the new domain before the redirect expires.

Discovering jemalloc and debugging native Java memory leaks

I’ve joined ThoughtWorks last August (awesome!) and I’ve been working with the tech team on everything related to infrastructure automation, code deployment and all things “DevOps” for GOV.UK Verify (part of the Government Digital Services). The last few months were very rewarding to me as I got exposed to a lot of different technologies, although I do tend to work a lot with Puppet most of the time and I don’t get the chance to look at other things “from the other side”. Working with the dev team on a Java memory leak issue was a great way to dig into something where I was already familiar with but I had the chance to understand a little bit more about JVM memory allocation, Linux kernel memory management and discovering great tools like jemalloc and the excellent jeprof profiler. We lost a long time playing the guess game and using the wrong tools before we found this excellent post by Evan Jones from Twitter. This led us to the discovery of jemalloc and I highly recommend having a look at it. It’s really worth it. We (Ozz) also wrote our story on GOV.UK Verify and we hope it can help others when dealing with similar native Java memory leaks.