Don’t Mess With My Resolv.conf

 Computing, Linux, Working Notes  No Responses »
Feb 092019
 

One of the things that irritates me about fancy new service management systems like systemd is that unless you get everything exactly right, you can end up with things interfering with specific configuration files – specifically /etc/resolv.conf.

Now as a DNS administrator, I have a certain fondness for manually controlling /etc/resolv.conf and it does actually come in useful for making temporary changes to test specific DNS servers and the like. The trouble comes when something else wants to control that file.

The ideal fix for this conflict is to have things like systemd control a separate file such as /etc/system/resolv.conf.systemd, and for /etc/resolv.conf be installed as a symbolic link pointing at the real file.

But back in the real world, if you do disable systemd-resolver which can be done with: systemctl disable systemd-resolved.service; systemctl stop systemd-resolved.service

Then you may also want to make the file immutable: chattr +i /etc/resolv.conf. On at least one server, systemd merrily re-created /etc/resolv.conf as a symbolic link to an empty file despite systemd-resolved being disabled.

Corner Of The Pyramid

Upgrading Linux Containers from Debian Wheezy to Jessie

 Linux, Working Notes  No Responses »
May 022015
 

I have recently been upgrading my Linux containers from Debian wheezy to jessie, and each time have encountered a problem preventing the container from booting. Or rather as it turns out, preventing the equivalent of init from starting any daemons. Which is systemd of course.

Now this is not some addition to the Great Systemd Debate (although my contribution to that debate may well arrive someday), but a simple fix, or at this stage a workaround (to use the dreaded ITIL phrase).

The fix is to re-install the traditional SystemV init package replacing the new systemd package. This can be done during the upgrade by running the following at the end of the usual process :- 

apt-get install sysvinit-core

Of course you will probably be reading this after you have encountered the problem. There are probably many ways of dealing with the situation after you have tried rebooting and encountered this issue, but my choice is to run the following commands from what I tend to call the "global container" :- 

chroot ${container root filesystem}
apt-get install sysvinit-core

As mentioned before, this is not a fix. And indeed the problem may be my own fault – perhaps it doesn't help having the "global container" still running wheezy. Perhaps there are some instructions in the Debian upgrade manual that details some extra step you should run. And of course by switching back to System V init, we are missing out on all of the systemd fun.