Missing init.d/apache2 file

Question

After trying to delete apache and tomcat, and now trying to reinstall apache 2, I am missing the init.d/apache2 file to start/stop my server.

I am not sure if the new install actualy worked, and my apt-get purge apache2 didn't remove everything in the first place!

How can I get the init.d/apache2 file to test if server starts / is installed properly (I had removed files and directories manually)?

Solution 1

Try using apt-get install --reinstall apache2 to force the apt-get system to install again even though the package exists and overwrite current files — even the ones it thinks are already there.

By manually deleting things from the system you undoubtedly have the package manager confused about what needs doing where. You usually want to stick to using the tools provided unless you understand what you are effecting by manually fiddling.

As an extra note, you don't usually need to mess with the files in /etc/init.d yourself. There is a tool that takes care of running those scripts for you. For example to restart apache you could run service apache2 restart.

Edited based on information found in comments

The init script is part of a sub-package. Installing a package for the first time will install it's dependencies, but uninstalling it will just uninstall the package, not it's dependencies. The init script that you manually removed belongs to the apache2.2-common package with was a dependency of the main apache2 package name. Removing apache2 even with --purge would have no effect on the init script because it's part of a different package. To get it back run apt-get install --reinstall apache2.2-common.

Edit2

Apparently Debian is wacky. I replicated the problem on a test system and was unable to get the init script back with the package manager. I found several other people with the same problem out on the web, and it looks like the solution is to manually download the package, extract it, and rip the file out like this:

cd /tmp
aptitude download apache2.2-common
dpkg --extract apache2.2-common_*.deb apache2.2-common
sudo cp apache2.2-common/etc/init.d/apache2 /etc/init.d

Edit3

Thanks to investigation done by Faheem Mitha and discussion on the comments below, a full answer to this question has worked out. Read Faheem's answer for full details. For humor value, here are the cliff notes:

The short version is that init scripts are considered conf files, and apt-get is too polite to touch conf files that have been user-modified in any way, even to restore deleted on reinstall after a uninstall. Before you say "duh of course", check out the gymnastics you have to do. I quote:

After asking the dpkg list (and being told off for it) + further fiddling, the following works. Be careful with this. It will replace all your modified config files with the version from the package. apt-get -o Dpkg::Options::="--force-confnew" -o Dpkg::Options::="--force-confask" install --reinstall apache2.2-common. I don't know why you needed me to tell you this. It's the first thing you should have thought of. :-) – Faheem Mitha

Solution 2

(I'm following up on Caleb's answer, though most of the relevant information will be in the comments already. I figure a summary might be more convenient than having to look through the comments.)

So, the issue, as described in Caleb's post, was that Alexander deleted (or possibly modified)/etc/init.d/apache2 and wanted to get it back. This file is in apache-2.2-common. The obvious apt-get install --reinstall apache2.2-common doesn't restore the file, though. The reason for this, per Debian policy, is that config files are not touched by the system once they have altered, unless explicitly asked by the user. See Debian Policy on config file handling: Section 10.7.3. Quote:

Configuration file handling must conform to the following behavior:

1. local changes must be preserved during a package upgrade, and

2. configuration files must be preserved when the package is removed, and only deleted when the package is purged.

Packages additions and removals are handled by dpkg. dpkg distinguishes two cases here, when the file is modified, and when it has been completely removed. See the section in the options section starting with --force-things in the dpkg man page. (Linking to Ubuntu's dpkg 1.16 page, because I could not find the Debian squeeze man pages online. If you have a pointer, please comment.)

So for the two situations

1. If you want conf files that have been removed to be replaced by reinstallation, you need to pass the --force-confmiss option to dpkg.

2. If you want conf files that have been altered, but not removed, to be replaced by their default version on installation, you need to pass both the --force-confnew and --force-confask options to dpkg. As the man page explains, --force-confnew by itself will only replace the modified conf file with the default in cases when the default is newer than the originally installed default, i.e. on an upgrade.

If we are invoking dpkg via apt, we need to pass these options to apt. This is done as follows for the two cases above :

apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall apache2.2-common

apt-get -o Dpkg::Options::="--force-confnew" -o Dpkg::Options::="--force-confask" install --reinstall apache2.2-common

I could not find any documentation for Dpkg::Options. I found it by Googling. If you know of any, please comment.

Comments:

1. I think if you are faced with a situation where you have messed up a config file and want to back, it is safer to rename it, and then use --force-confmiss rather than asking for all your local modifications to be replaced by the default per --force-confnew, which is in general not what you want.

2. If working with config files, always keep them under version control. This would make the issues of messed up config files moot. I use and recommend mercurial. In this case (and probably any case :-)), you are better off in this context using distributed version control than a centralized version control system like subversion. A good program for doing this is etckeeper.

3. It is also worth mentioning, and might have contributed to the confusion here, that with apt in squeeze, apache2.2-common does not uninstall cleanly, because of apt bug 621720, which coincidentally covers the case of apache2.2-common removal. Per the bug report you will need to use

   apt-get remove apache2.2-common -o pkgProblemResolver::FixByInstall=0`
   

   (verified by me).

4. See Everything you need to know about conffiles: configuration files managed by dpkg for a discussion of dpkg's config file handling by Raphaël Hertzog, one of dpkg's developers. He mentions that --force-confask is new in Squeeze. He also mentions that

   dpkg --status apache2.2-common
   

   gives the list of conffiles, along with other information. or just

   dpkg-query --showformat='${Conffiles}\n' --show apache2.2-common
   

   if you only want that information.

Thanks to David Kalnischkies and Raphaël Hertzog for answering my questions about this (and telling me I was posting to the wrong mailing list). I think the Debian documentation in this context could be improved, and specifically, the dpkg man page could do with additional usage examples. I encourage people here (who are obviously willing to help out) to also take time to contribute documentation patches to free software projects like Debian. It is valuable work and there are not enough people doing it.

Solution 3

I had this exact same problem on a Debian system. It affected both apache and nginx.

All solutions here did not work for me; purging, reinstalling, downloading and manual install and Dpkg::Options didn't work.

It turns out one of the dependencies creates the config files needed to start and stop the services. You simply remove all dependencies and do a fresh reinstall.

I found the solution here: http://dancingpenguinsoflight.com/2009/02/how-to-completely-reset-an-apache-instance-in-ubuntu/

APACHE_PKGS=`sudo dpkg --get-selections | grep apache | cut -f 1`
# Make sure things are sane:
echo $APACHE_PKGS
# Example output: apache2 apache2-mpm-prefork apache2-utils apache2.2-common \
# libapache2-mod-php5 libapache2-mod-python libapache2-svn
# Likely if you have a Python application:
# libapache2-mod-python libapache2-mod-python-doc libapache2-mod-wsgi
# Or if you roll with the PHP: 
# libapache2-mod-php5
sudo apt-get remove --purge $APACHE_PKGS

Comments

[Admin]

debian packages aptitude / apt0get install apache2

[Admin]

apt-get install . .

[Admin]

shouldn't that file be created automatically, and it not being there is an indication that my purge, as well as reinstall didnt work !/

[Admin]

I suggest an integrity check. You can try debsums -s. This might point out if any of your packages are badly damaged.

[tcoolspy]

In my Debian 6.0.1 system the init script belongs to the apache2.2-common package. You can find this relationship out for any file on the system with dpkg -S /path/to/file.

[tcoolspy]

Since the init script belongs to the -common sub-package, it is likely that you only removed the main package and didn't actually remove all the related sub-packages. The you manually removed a file belonging to the sub-package. In this case re-installing just the main package won't help at all. You should apt-get install --re-install apache2.2-common to get the files associated with that package back.

[Alexander Grosse]

unfortunately it does not restore my init-script. I am unable to restore it / or rather seem to be unable to properly reinstall the Apache package. Maybe my question should be, how I properly clean up / delete previous installed packages and all dependencies / folders + files with it.

[tcoolspy]

I'm not enough of a Debian expert to say why apt-get is apparently mis-behaving so badly, but I was able to both replicate the problem here and find references to other people with the same issue. The only solution I found was manually extracting the package; see my edited answer.

[Alen Milakovic]

@Caleb: You say "I replicated the problem on a test system". I'm unsure what the problem is. Can you provide a reproduction recipe? Is it related to bugs.debian.org/621720? If you find a problem and it has not been reported already, please file a bug report. Thanks.

[Alen Milakovic]

Note Debian Policy on config files. See "However, note that dpkg will not replace a conffile that was removed by the user (or by a script)." etc. etc.

[tcoolspy]

@Faheem That's awfully gentleman of Debian not to mess with conf files, but is there no flag or option anywhere to override this behavior? For example RPM can be asked to create conf files with an alternate extension as an alternative to clobbering edited ones.

[Alen Milakovic]

@Caleb: One option is to remove it completely, and do apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall apache2.2-common. I verified this works. If the file is modified and not missing, it seems to me thatapt-get -o Dpkg::Options::="--force-confnew" install --reinstall apache2.2-common should work but doesn't. See man dpkg, and the section beginning --force-things. It's not the best documented feature. I'll ask about this latter thing. No doubt I'm missing something.

[tcoolspy]

@Faheema I was just about to type that, then decided naw it would be too simple. Sheesh, what a command. Thanks for tracking it down with the dpkg folks tho. If you want to add that as an answer here go ahead. Until then I figured it warranted the attention of adding it to my answer.

[Alen Milakovic]

@Caleb: I'm just posted a summary of what was in the comments, with brief explanations and context. Feel free to comment if you think further clarifications are needed. Thanks.

[Ruiz Deang]

Been trying to solve this for about an hour on Crunchbang Waldorf, which is functionally Debian Wheezy. This was the answer that actually worked for me. All files in /etc/apache2 appear to have been restored.