Sign up ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sometimes installing some applications will start a process or service from the application being run automatically on installation. How do I install without starting them?

share|improve this question
I wonder what potential there is to leave a system in an unstable state when installing kernel or DKMS packages using this kind of configuration. I don't know much about this area. – ændrük Nov 4 '11 at 19:26
@ændrük That has got me worried. You see I'm installing minimal Ubuntu on a drive, then instead of booting into it, I use a Live CD/USB to chroot and install the packages I need. Of course drivers, specifically, GPU drivers are not there and needs to be installed. – Oxwivi Nov 5 '11 at 5:06

6 Answers 6

up vote 22 down vote accepted

There's a slightly hackish, but quite reliable way to do this which I've been using for a while in an automated installation script.

First create a directory, for example /root/fake, which contains symlinks to /bin/true called:


You could also make them bash scripts that do nothing and return success.

Then include that directory at the front of $PATH when installing packages:

PATH=/root/fake:$PATH apt-get install whatever

This only prevents daemons from starting/restarting, while things like creating an initramfs are still being done.


The scripts which are being executed at package installation and removal execute invoke-rc.d or others of the mentioned commands to start and stop services. They don't however call them with absolute paths (at least I haven't encountered one that does).

So by inserting the faked "no operation" commands at the beginning of $PATH, the real commands never get called.

Since only the commands used to start/stop services are being faked, everything else, in particular important tasks like updating/creating initramfs-images still work.

share|improve this answer
Not quite familiar with symlinks, can you elaborate with all the steps you take? – Oxwivi Nov 9 '11 at 18:47
A symlink is a special type of file that has no content, instead it refers to another file (by path/name). They can be created with ln -s, in this case for example ln -s /bin/true /root/fake/initctl. – bseibold Nov 9 '11 at 20:18
How does it prevent daemons from starting/restarting? According to @psusi's answer invoke-rc.d is responsible. – Oxwivi Nov 10 '11 at 7:08
By placing the directory with the faked commands at the beginning of the $PATH variable, all calls to invoke-rc.d and others that can be used to start and stop daemons use the fake commands. That is, unless they are called with an absolute path, but I have never encountered this. – bseibold Nov 10 '11 at 14:00
Ah, now I see how it works - basically, the symlinks leads to dead ends. But what exactly is the /bin/true thing? And what of the rest of the commands involved in the packages? Won't they get thrown off-track by the specified $PATH? – Oxwivi Nov 10 '11 at 14:07

Background daemons are started with invoke-rc.d, which makes sure that the daemon is not started if its rc script says it is not supposed to run in the current system runlevel. You can override its idea of the current system runlevel by setting the environment variable RUNLEVEL. Nothing is supposed to run in runlevels 0 and 6, but it appears that invoke-rc.d is buggy and runs things anyhow if you use these runlevels. Most daemons do not run in runlevel 1, so you can prevent them from being started on install like this:

sudo RUNLEVEL=1 apt-get install redis-server
share|improve this answer
I'm installing minimal Ubuntu on a drive, then instead of booting into it, I use a Live CD/USB to chroot and install the packages I need. Because of the things starting to run, sometimes I'm switched out of the ubuntu (live CD) session. Anyway, the thing I want to ask is, how do I use this RUNLEVEL in chroot? – Oxwivi Nov 5 '11 at 11:43
@Oxwivi, the same way, but it is supposed to automatically detect you are in a chroot and skip starting daemons. – psusi Nov 7 '11 at 14:43
Is it possible the buggy invoke-rc.d is responsible for the issues I faced? – Oxwivi Nov 7 '11 at 15:24
@Oxwivi, it is possible, but more likely that a particular package is buggy and isn't using invoke-rc.d. What package was this? – psusi Nov 7 '11 at 15:29
I have no idea, I just listed all the packages to install and did not mind the terminal further to view the output. – Oxwivi Nov 7 '11 at 16:08

What I ended up doing is emulating what debootstrap does when installing packages, except I used dpkg-divert:

First move the real files out of the way:

dpkg-divert --add --rename --local /sbin/start-stop-daemon
dpkg-divert --add --rename --local /sbin/initctl

Then create dummy versions:

echo \
echo \"Warning: Fake start-stop-daemon called, doing nothing\"" > "/sbin/start-stop-daemon"
chmod 755 "/sbin/start-stop-daemon"

echo \
echo \"Warning: Fake initctl called, doing nothing\"" > "/sbin/initctl"
chmod 755 "/sbin/initctl"

Then do your apt-get upgrades, installs, etc., and then clean up with:

rm /sbin/initctl /sbin/start-stop-daemon
dpkg-divert --remove --rename /sbin/initctl
dpkg-divert --remove --rename /sbin/start-stop-daemon

I know there are other commands that can be used to stop/start services, but debootstrap only cares about start-stop-daemon and initctl, so I followed suit.

share|improve this answer

A quick one-liner:

echo -e '#!/bin/sh\nexit 101' | install -m 755 /dev/stdin /usr/sbin/policy-rc.d && apt-get install **Package** && rm -f /usr/sbin/policy-rc.d
share|improve this answer
With regards to the person who put the "quick one-liner", you forgot to set /usr/sbin/policy-rc.d as executable. It'll be ignored otherwise. – user191809 Sep 10 '13 at 20:19

There is better solution here:

cat > /usr/sbin/policy-rc.d <<EOF
exit 101
chmod a+x /usr/sbin/policy-rc.d
share|improve this answer

I believe you need to use the --no-triggers command line option when you do the dpkg install. Something like this:

dpkg -i --no-triggers SomeBigPackage.deb

To make this setting persistent so that apt-get install does not run any triggers, create a custom dpkg configuration file in /etc/dpkg/dpkg.cfg.d/custom:

# Install packages without starting background processes and services
# See  

Note that dpkg still logs triggers as having run even though they haven't:

$ sudo apt-get install redis-server 
Starting redis-server: redis-server.
$ service redis-server status
redis-server is not running

Alternatively, you can have the installer script run the service command to turn off the new service:

service name_of_service stop
share|improve this answer
Any apt-get equivalent? Or is there a way to configure dpkg to run with --no-triggers whether using dpkg directly or apt-get to install something? – Oxwivi Nov 2 '11 at 7:53
dan_linder, I hope you don't mind me editing in a answer to @Oxwivi's question. Feel free to modify/revert it if it's not to your liking. – ændrük Nov 4 '11 at 19:21
This is incorrect. Triggers have nothing to do with starting daemons. Triggers are one package performing some action to reconfigure itself in response to another, such as if you install a package that adds an initramfs hook, it triggers the initramfs-tools package to rebuild your initramfs. – psusi Nov 4 '11 at 19:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.