One of the basic principles of computer security is never to run anything you don't need.

I was pgrepping for a process today when I noticed that my Ubuntu 9.04 (desktop) machine was running a git server daemon. After a quick swear, I discovered that the git-daemon-run package had been (probably inadvertently) installed, and removing it got rid of that process (and ensured that it wouldn't be restarted later).

But in other cases, I want the server package to be installed, but don't want the server daemon running. For example, I use lighttpd for internal testing (it's started by specific test scripts for some applications, and listens only on localhost in those configurations) but I don't want it listening for outside connections with some random config file. (If I wanted to run one listening for outside connections, I'd configure and run it myself.)

I really don't like running all sorts of random servers I don't need on Internet-exposed machines, since who knows what security holes they open up. And I prefer not to have to muck about with firewalls, since that's yet another potential source of errors and misconfigurations that can open up security holes. It's not so hard to have Unix machines configured not to start any servers unless specifically asked to do so by the admin; NetBSD (and OpenBSD, too, I think) come this way by default.

How do I configure my Ubuntu systems never to start any kind of server daemon unless I specifically tell it I want it started?

(Asking to have a package installed is not, in my book, asking to start a server. If it is supposed to be, it's a terrible user interface, since many package installs don't even have a server to start, so it makes it far too easy to inadvertently start a server without realizing you've done so.)

EDIT: Just to make it clear, the problem is not that I want to be able to stop existing servers. The problem is that I don't want new servers started without an explicit request. This means I should be able to do any sysadmin task, such as installing a package, and be confident that no servers have started. Most responses do not address this point.

  • 3
    I've poked around inside of .deb packages for about 10 minutes. They include a "postinst" script which is run after the package has been installed. The last command that they run is often "invoke-rc.d <servicename> start" which causes the service to start itself. The call to invoke-rc.d is usually hard-wired in without any check of a global configuration variable to control whether or not to actually start the service. Thus, it would be up to invoke-rc.d to make a decision about whether to start the service. That's where my investigation ended. Jun 22 '09 at 9:46
  • 2
    as Barry explained, Ubuntu is clearly not for you. Sorry, but you have to 1) change distro, or 2) keep a good eye on whatever ubuntu is doing.
    – elcuco
    Jun 22 '09 at 20:30
  • The reason Ubuntu/Debian differ from Fedora in this respect, is Debian only installs what you ask, whereas Fedora install the kitchen sink. So in Fedora it's common to have a package installed that you didn't ask for, so it defaults to not running. In Debian, you explicitly installed the package, so it's expected you want the server running immediately.
    – TRS-80
    Jun 23 '09 at 4:01
  • any updates. Which one did you try? and what worked? a May 4 '11 at 14:45
  • Sad to say, there appears to be no solution other than, "carefully check what software is running on your system after any change of packages," clearly a quite error-prone process.
    – cjs
    Oct 27 '12 at 15:16

13 Answers 13


Install sysv-rc-conf and simply turn off the services you don't want to have running.

sudo apt-get install sysv-rc-conf
DESCRIPTION: sysv-rc-conf gives an easy to use interface for manag‐ ing "/etc/rc{runlevel}.d/" symlinks.

alt text

  • How does this keep new servers from being turned on by the packing system?
    – cjs
    Jun 22 '09 at 6:06
  • Please read the comment by Barry Brown, it explains why this answer is obslete.
    – elcuco
    Jun 22 '09 at 20:29

As someone with a similar problem, I feel very strongly that it is not reasonable for a daemon to presume that the user wants it started per default: There are a many perfectly valid use cases where this is not the case. (Not to mention that it is not always clear which installations actually include a daemon.) The daemon could be off per default, the user could be explicitly queried, or there could be a central setting. Anything else is Microsoftian reasoning entirely unworthy of Linux.

In addition, I find several of the above comments to the original poster to be rude, patronizing, and lacking in constructiveness. To suggest, e.g., that he should either accept the default behaviour or change distribution is truly remarkable. Firstly, no distribution will be a perfect fit, and jumping to a new distribution with associated extra work is unlikely to be a realistic solution over this one thing. Secondly, proficient Linux/Unix users are used to every behaviour being changeable: A problem may take two hours off digging, but then it is fixed. The natural thing for such a user to do, when the defaults are unsuitable, is to assume the existence of a work-around and try to find out what it is. Thirdly, in open source and free software etiquette, If you don't like it, then patch the source code!'' is an acceptable response; however,..., then take a hike!'' is not.


The expectation of the packaging system is that when you install a server package, you want to run that server. It is a reasonable expectation.

How do I configure my Ubuntu systems never to start any kind of server unless I 
specifically tell it to I want a server started? 

Roy has answered this question for you. When you install a new server package, you stop that server and then use a tool like sysv-rc-conf to prevent that server from being started at the next reboot or runlevel change. Yes, you have to do some work yourself, and that's reasonable because you're configuring your system differently to most people who use Ubuntu.

For example, I use lighttpd for internal testing (it's started by specific test scripts 
for some applications, and listens only on localhost) but I generally don't want it 
listening for outside connections.

You should invest some time to learn how to configure lighttpd so that it is permanently configured to only listen on localhost. Then, when you do start the server, you know it's already configured to your liking.

  • 3
    First, I don't think it's a reasonable expectation; that I've installed a lighttpd binary doesn't mean I want to run a public server. Second, I don't always know that I've installed a server package; they sometimes get pulled in by other packages that I've installed.
    – cjs
    Jun 22 '09 at 8:08
  • 1
    Oh, and I do know how to configure lighttpd to listen only on localhost, and I often have a half dozen or more checkouts of projects on any particular system that do so.
    – cjs
    Jun 22 '09 at 8:08

I found the following helpful for installing Ubuntu in chroot environments, like debootstrapping new xen guests. Credit actually goes to the xen-tools scripts for teaching me this:

echo '#!/bin/sh' > /usr/sbin/policy-rc.d

echo 'exit 101' >> /usr/sbin/policy-rc.d

chmod 755 /usr/sbin/policy-rc.d

With this script in place, apt will not start services after install. However, this is only half your problem, because symlinks are still put in place, the services will start after the next boot. I don't know how to automatically stop that :(

  • 1
    it can break nginx logrotation because Ubuntu's /etc/logrotate.d/nginx use invoke-rc.d nginx rotate in postrotate section I'm using version which is slightly different gist.github.com/hostmaster/7c25ef4e1e47bc3e2d71
    – hostmaster
    Nov 28 '14 at 12:39
  • It also prevents daemon from stoping when it's packages deletes from the system. This is not good.
    – hostmaster
    Dec 1 '14 at 16:39

Barry Brown, in a comment on the question, provides a clue to a possible answer.

The packaging system uses the invoke-rc.d program to start the server after the package is installed.[1] This program will run /usr/sbin/policy-rc.d to determine the policy on starting that server.

The package policyrcd-script-zg2 includes the policy-rc.d script, which either runs /etc/policy-rc.d with its parameters if present, and exits with that script's error code, or exits with 0 (success) otherwise. The interface policy-rc.d is expected to offer is documented briefly in the invoke-rc.d manage, and much more extensively in /usr/share/doc/sysv-rc/README.policy-rc.d.gz.

The next step, I suppose, is for me to test this.

Things remaining to be answered:

[1] What other parts of the system use invoke-rc.d? [2] Does this actually work?


How about watching on the directories where the init scripts are located? You can likely make those directories unmodifiable with the chatr command.

  • Hm. I wonder why this one was downvoted? It's a hack, but at least it addresses my issue, unlike most of the responses here.
    – cjs
    Jul 1 '09 at 2:47
  • I upvoted this because it is the closest solution you're likely to get with Ubuntu, although I think that making the init directories unmodifiable is a terrible idea (Just imagine trying to install a service that you WANT to start). I know that find can be used to monitor changes in files and directories, although I'm not familiar enough with the tool to give you an exact command. I would ask one of the gurus for a working command, stick it in a bash script, and run it after each install, then use sysv-rc-conf to manually disable the services you don't want.
    – Babu
    Jul 11 '09 at 5:35

Ideally, this is a matter of post-inst scripts. At the beginning of the Ubuntu project, an intentional effort was made to force sane defaults to dpkg configuration scripts, so that you and I don't have to answer every damn question that might come up, or waste time researching the options. Now that Ubuntu has set this up, many people aren't aware it exists. It should be possible to ask a question about whether to install as a daemon or not, but I don't see any such questions in the few packages I checked.

Perhaps you should engage with the Ubuntu Server Team and maybe even Debian Policy to improve things.


You can try to create script that will check up list of installed services and verify them against some list of permitted services. If service is not in the list then script will turn it off. The script must be run at start before common services. And maybe run like daemon to shut freshly installed services. Or if possible to run automatically after each install to check for new services.

P.S. I can think of two possible causes of services start after package install. That is package feature, or that is package manager feature. If that is package feature i dont think there is some way to change service behaviour. If that is package manager feature maybe there is some configuration option to prevent service start after install. I dont know right now so just throwing ideas.


If you set up iptables with a default policy of DROP for the INPUT chain then you don't have to worry as much about listening ports because they will be blocked by iptables. Ubuntu server comes with a user friendly interface for iptables if you are new to iptables.

From your post, it sounds to me like you might be happier with a different Linux distribution such as CentOS. The default install process for CentOS will allow you to install different meta-packages, and by selecting none you might be happier with your base install.

Also, I think you question might have a been a bit clearer if you substitute 'service' or 'daemon' for the word 'server' when you mean something that runs on a server. People tend to use 'server' to refer to a physical box or VM. Although I guess its not technically incorrect.


Take a look at what run level you're in with the 'runlevel' command, and remove all the symlinks at /etc/rc<runlevel>.d/. You'll probably want some of the daemons running, but most could probably be removed.

You can add them back in with a symlink from the script in /etc/init.d.

I think there is a command that'll do that same trick, and add all the symlinks for all the runlevels, but I just do it manually.

  • The issue is, I don't know when symlinks might be added. I need to prevent whatever is adding symlinks and starting servers (the packaging system, mainly, it seems) from doing so unless I take some action that specifically asks it to do so.
    – cjs
    Jun 22 '09 at 5:20
  • Probably easier and more reliable to just set up a firewall. Maybe script something up to take a port and protocol as an argument to add/del firewall rules to make things easier.
    – resonator
    Jun 22 '09 at 5:43
  • or run your machine in single user mode... That might introduce more problems than it saves though.
    – resonator
    Jun 22 '09 at 5:48
  • I'm new to Ubuntu, being a longtime Fedora/RedHat user. That's one thing about Ubuntu that strikes me as odd: services are on by default. Under Fedora, services are off by default. Jun 22 '09 at 5:57
  • Running a desktop machine or server in single-user mode is not very practical.
    – cjs
    Jun 22 '09 at 6:05

Alternatively, you could use update-rc.d command.

To disable apache2 service

# update-rc.d [-f] apache2 remove


This means I should be able to do any sysadmin task, such as installing a package, and be confident that no servers have started.

This behaviour is controlled by scripts inside .deb packages. When you install a package, this script is executed automatically. IIRC, we can't bypass this script.


Basically, you can't.

If you install a package and it starts a service then that's what happens. If you don't like then file a bug at https://launchpad.net/.

You should not muck around with deb packages. This sort of thing could come back and bite you in the ass later on.

If you want OpenBSD-style 'nothing running by default', then run OpenBSD. Not every distro suits everyone. There's bound to be things in Ubuntu that you don't like. If you still want to run ubuntu, then you'll have to check the running services and turn things off.


You can enable and disable some services in System > Services menu in GNOME

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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