/etc/default/apache2: NO_START

True, but 'apache2ctl start' still works fine, so this is only a minor annoyance.

Created an attachment (id=4904)
patch to add force-start option

This patch adds an option "force-start" that does the same as "start" except
that it ignores $NO_START.

No offense, but why does /etc/default/apache2 even exist?

We have runlevels to enable/disable starting apache2 on boot (or not)...

To seems totally redundant, and just plain weird... I just spent two hours, searching why apache wouldn't start.

Service should be start the /etc/init.d way, and in case of apache not throught apache2ctl.

You'll note at /etc/default/apache2 is only written in the way it is IF you have something else bound to port 80 when the package is installed. This is mostly a safety thing so users can install multiple webservers without having their init scripts blow up in the default config.

Yes, but apache2 could also just have been removed from runlevel 2-5 to prevent it from starting on boot, that's why we have runlevels.

And then the user has no idea how to get it back in those runlevels in the approrpriate S/K order. I tend to think of runlevel symlinks as something for the user/admin to touch, NOT something for packagers to use to enable/disable the world.

And, to be honest, this bug report makes it seem like this is an odd or unexpected behaviour, when usage of /etc/default/* this way it well-established in the Debian world by now.

I find it strange that there's no output, if you call "/etc/init.d/apache2 start" with NO_START=1 (because of VERBOSE=no by default in /etc/default/rcS).

I think the message "Not starting apache2 - edit /etc/default/apache2 and change NO_START to be 0." should get displayed always.

I have had this issue as well, and it is definitely a bug. Not displaying an error message when there is an error is *COMPLETELY* against the Unix way of doing things. Silence = success, message = error. I spent days trying to figure out why I couldn't start my Apache after upgrading to Fiesty Fawn.

If a configuration file says that it shouldn't start it's not an error. It's behaviour by design.
I can see, though, that the reason it doesn't start should perhaps be more obvious.
Stay tuned :)

Yep, I agree that this is a problem. I spent about an hour trying to work out why it wouldn't start. Running
    /etc/init.d/apache2 start
does nothing, outputs nothing, and returns success. Also the comment in the script which says
    "Stupid hack to keep lintian happy. (Warrk! Stupidhack!)."
is not what I'd expect to see in a project of this cailbre.

Some other comments.

Firstly, I am not that familiar with apache, and so have never heard of apache2ctl. All I know is that on at least Debian/Ubuntu systems, the convention for starting a service is to use /etc/init.d. So when this doesn't work, it is more than a minor annoyance.

Secondly, the /etc/default/apache2 file says that NO_START controls boot behaviour, so why is it affecting behaviour when I try to start it myself? I agree that boot behaviour should be controlled by runlevels, but think Adam Conrad has a very good point about people like me not knowing how to restore the runlevel scripts. Therefore, I think the proposal by dAniel hAhler is the best.

Third, if the contents of /etc/default are dependent on what is bound to port 80 at install time, then there should DEFINITELY be a comment in there which says as much. In my case I assume it was apache that was bound to port 80. I only removed apache after installing apache2.

Even if the /etc/default/apache2 thing is from keeping things blowing up when having multiple webservers installed. This is _not_ the way.

What next? ftp servers? jabber servers?

I highly suggest that packages which install a webserver automatically remove all other webservers from /etc/init.d for example.

This is a plain mess.

And we should _not_ make installing a webserver easier for folks who know nothing about them, that's a security nightmare waiting to happen.

Pascal, I disagree with you on your last point. User-friendliness and security should be kept orthogonal. Making something hard to use is not a good way of achieving security.

To some degree you're right, it should be kept orthogonal when it does not interfere with keeping the system clean.

Having two settings to enable apache is not acceptable...

We have the init system for a reason. That should be used.

We should make the init system user friendly by making a good GUI/CLI tool for it, not by providing intentionally broken init scripts.

We can use RedHat chkconfig as an example, which is easier to use and provides an administrator with more oversight than update-rc.d. update-rc.d is arcane when compared to chkconfig.

Problem is fixed in 2.2.4-1

Thanks!