Feedback

type to search

Welcome

Wiki pages

Top 5 groups

Top 5 users

Recent badges

How to prevent daemons from starting at installation time?

Asked by [ Editor ]

Upon installation of a package with a daemon many packages kindly start the daemon as well. A few examples that come to my mind would be openssh-server, apache2, ejabberd, tor, munin and uucp (it adds cron jobs). However in most cases this is not what I want. For example ejabberd is useless in its default configuration, because it cannot peer with any other servers before configuring a domain to work on, so it really should not be started before being configured. Many daemons open a tcp port binding 0.0.0.0 and this is not always intended (binding a private network is often preferred). For most of the daemons I would like to read the documentation before having a some software running of which I do not know how it works. So how can I achieve this?

NN comments
alex
-

That’s a very good question. I’ve been in the same situation lots of times, when installing or upgrading a package with a related daemon makes it to start (or restart) automatically. It really doesn’t seem like a good (or desired) behavior, so I’m interested in learning how to prevent daemons from starting/restarting automatically during install or updates.

helmut
-

Please stop spamming the answer section with comments repeating the question.

or Cancel

4 answers

1

he@debian.org

Daemons are (in policy-conforming packages, which should be all by now) started at installation time by using the invoke-rc.d script in the maintainer scripts. invoke-rc.d itselfs tries to call /usr/bin/policy-rc.d, which is asked if the local policy allows a certain action for some init script.

You can use this mechanism to define a whitelist of services which should be controlled by invoke-rc.d (i.e., everything that you have already installed and configured) and deny all actions for other, unknown, services. This would ensure that unconfigured daemons are not started at installation time. I’m not aware of an existing implementation of this, but it should be easy to implement in a few lines of shell script. You can find the documentation for policy-rc.d in /usr/share/doc/sysv-rc/README.policy-rc.d.gz on any Debian system.

NN comments
helmut
-

As far as I understand it policy-rc.d is not used by the init scripts, so the policy-rc.d result is not used during boot or shutdown. This makes it a bit cumbersome to use, but indeed this looks promising. The policyrcd-script-zg2 package is also useful to avoid writing configuration to /usr/bin.

or Cancel
0

overholw

Debian is trying to find the path of least surprise/confusion for users.  The package maintainers do their best (in conjunction with upstream) to find sensible default parameters.   The question I think is far more complex than your question implies.


In the usual case, an admin or user installs a service and expects it to out of the box.   Based on this the developers try to find sensible default parameters.   I think Debian policy is also that if a server service is installed, it should start automatically.   Imagine the reverse case, if no services started automatically, then there would be a huge number of bugs of the class “I installed foo-server and it doesn’t work”.   Additionally, every time someone builds a system, they would have to remember to start all of the services.

I acknowledge that there are services where there are no sensible defaults.   Many of these (example: postfix) prompt to get settings that are reasonable for 95+% of users.   I haven’t used ejabberd, to comment on it’s configuration.   At least one other service I recently looked at required being enabled in /etc/default/[service] to start automatically.     Maybe it’s configuration process can be improved.   Please read the bug reports on it (active and closed), and then try to constructively add to the discussion.

For your question of exploring a new package, there are several layers of response.   Frequently there is a [server]-doc package, installing that first will frequently help.  I usually visit the upstream website before I install a package.  I always install it on a test environment before putting it where it is internet accessible.   For example my laptop is almost always behind a NAT.   Going one step farther, I have been creating virtual machines (eg using: VirtualBox, qemu, VMWare, etc) when appropriate.       

On your question of binding to private networks only, the problem is determining what a private network is and what the appropriate default is for all users.    A number of companies are using 192.168. or 10. or 172.?. as their working internal address space.   Many home routers/NAT devices use 192.168. as private.   What set of rules is appropriate/correct given this variety?   How does that mesh with the default expectation that a server installed will be providing useful services on a default install.

I don’t disagree with the intent of your question.   
As an admin of a number of Debian servers, I have to sort through all of the services running and make sure that they are configured appropriately.    I take the approach of minimizing the number of installed services on every machine, rather than worrying about securing the unneeded services.    
There may be a better way to configure specific packages, that is almost certainly done best by working with the package maintainer after reading the bug reports.

:  If a package is causing a daemon to restart, it usually believes that it is making relevant configuration or system changes that the daemon needs.   For example some services don’t work properly if they are not restarted with a libc6 upgrade.  Other software needs (or works better) if the related service is running, not starting that service causes problems that generate bug reports (or worse annoyed users leaving for a distro that does things differently).    
NN comments
helmut
-

Thanks for your effort. Unfortunately your very long answer does not include much content. I’d summarize it to: 1) You don’t know an answer. 2) Debian has to pick defaults and starting daemons is kind of a sane default (agreed) however the knob for changing this default is missing (problem). 3) Some unrelated stuff.

alex
-
the point is that a package should not start / restart a daemon unconditionally (which happens with many packages). I really appreciate having sensible default settings and behaviors. However, I think it wouldn’t be too hard for a package to ask a simple question instead of acting according to defaults that might not be appropriate in certain cases (“Service abc has been updated and should be restarted because xyz. Do you want it to be restarted now?”). If I’m not mistaken, that’s what happens after a libc6 upgrade : the system notifies / asks the user about services that should be restarted.

or Cancel
0

linulin [ Editor ]

If maintainer designed a package to start some daemon at installation time, you can't prevent this in general. Some packages allow controlling the startup behavior via relevant configuration files located in /etc/default directory, (although this method is not standardized). The following heuristic may help to discover the control options of interest for already installed packages:

egrep ‘ENABL|DISABL|START’ /etc/default/*

This means that you have to create the configuration file in advance if you really need to prevent particular daemon from starting during the installation. Usually, you are given a chance to compare the file with the package version at installation time, and edit the final version if necessary. Therefore, it does not need to be 100% correct from the very beginning.

If there are strong (e.g. security-related) reasons why a daemon must not be started automatically, you should describe them in a bug report, and hopefully, maintainer of the corresponding package will change its behavior.

NN comments
helmut
-

The method you describe is unreliable (not every package has a default file). It is also cumbersome, because this is no single knob, but a knob for each package to install. This means I need to know parts of the package prior to installation which is the chicken and egg problem my question asked to solve. Still this answer is possibly the best of the three proposed so far.

or Cancel
-1

adam.trickett [ Editor ]

I’ve seen this asked as a question before (not here I may add), in the context of daemons for servers, where you may want to install the packages but would never dream of switching it on in a hostile environment without configuring it first. SSH was one example I saw but I’m sure that there would be others.


I think what is thinking is, could there be a flag you set in your apt config such that when a package with a daemon is installed you can choose if it starts automatically or not?
NN comments
or Cancel

Your answer

Answer by email
You need to join Debian to complete this action, click here to do so.