How to Install Packages Without Starting Services on Ubuntu/Debian

debianpackage-managementUbuntu

As you're probably aware, by default when you install a package on a Debian or Ubuntu based system, if the package contains a service, that service will generally be enabled and started automatically when you install the package.

This is a problem for me.

I've found myself needing to manage templates for building LXC containers. There are several containers, each corresponding to a Debian or Ubuntu release. (There are also Red Hat-based containers, but they aren't relevant here.)

/var/lib/libvirt/filesystems/debian6_template
/var/lib/libvirt/filesystems/debian7_template
/var/lib/libvirt/filesystems/ubuntu1004_template
/var/lib/libvirt/filesystems/ubuntu1204_template

Occasionally I will find that the templates have a missing package or need some other change, so I will chroot into them to install the package. Unfortunately when I do that, I wind up with several copies of the package's service running!

By way of example, I found the templates didn't have a syslog daemon, so I installed one:

for template in /var/lib/libvirt/filesystems/{debian,ubuntu}*_template; do
    chroot $template apt-get install rsyslog
done

And promptly wound up with four copies of rsyslog running. Not to mention two copies of exim4. Oops!

I read somewhere (though I can't find it again now) that it's not supposed to start services when running in a chroot, but that clearly isn't happening here.

One potentially viable nasty hack calls for temporarily replacing the various commands which actually start services, such as start-stop-daemon and initctl, though this is a lot more work than I really wanted to do. If I have no other choice, though…

The ideal solution here would be for Debian-based systems to stop doing this crap, but failing that, perhaps an obscure or undocumented command line option for apt-get?

In case it wasn't clear, I really want to keep anything related to managing the templates outside the templates, if possible.

Best Answer

For debian you can do this with policy-rc.d. Here's one explanation:

A package’s maintainer scripts are supposed to only interface with the init system by means of invoke-rc.d, update-rc.d and the LSB init script headers... invoke-rc.d will, before taking its action, check whether /usr/sbin/policy-rc.d is executable, will call it with the respective service name and the current runlevel number on its command line and act according to its exit code. For example, a return value of 101 will prevent the planned action from being taken. This includes the automated start of the service upon package installation as well as the stop of the service on package removal and reduces the stop-upgrade-restart ritual during package upgrades to just performing the upgrade which might leave the old version of the service running

Since you don't want any services to ever start, your policy-rc.d script can be simply

#!/bin/sh
exit 101

This is the technique used by tools like pbuilder and Docker's mkimage-debootstrap.

Unfortunately, this technique does not work with Ubuntu chroots. Packages that integrate with the upstart init system call /usr/sbin/initctl instead of invoke-rc.d during installation, and initctl doesn't consult policy-rc.d. According to upstart's author the workaround is to replace /sbin/initctl with a symlink to /bin/true in a chroot. You can see this in mkimage-debootstrap as well, they do

dpkg-divert --local --rename --add /sbin/initctl
ln -sf /bin/true sbin/initctl
Related Topic