Centos – Difference between `httpd -k start` and `service httpd start`

apache-2.2centoshttpdservice

Normally, I restart httpd on my development "CentOS 6.5 (Final)" box using service httpd restart, or service httpd stop followed by service httpd start if I'm feeling paranoid.

However, after weeks of searching, tweaking, updating, and recompiling a "broken" PHP module (SpiderMonkey) to no avail, I have on a whim started apache using httpd -k start command — and the module suddenly appears!

What's the difference? Can I correct the service httpd start|stop|restart behavior?

NOTE: In my initial attempt to correct the problem, I installed php55w from the webstatic repo. I'm assuming, had I had the whim prior to doing that, the solution (to restart using httpd -k) would have solved the problem, since that's how apache is normally restarted in production (where the module works).

Best Answer

examine the service

service httpd start|stop|restart invokes a service wrapper, which effectively means that httpd itself is being triggered through scripted methods that likely do something more than just calling httpd. an example of this is that they might write a PID file in a particular location in order to keep track of the currently running httpd process.

it's hard to say what might be causing the specific issue that you are seeing, but i suspect that inspection of the service wrapper would give you all the clues you need. a typical location for your service wrapper might be /etc/init.d/httpd.

confirm http used

probably, you'll want to try 'which httpd' and compare that to the http path you find in the service wrapper. maybe what you are seeing is a simple case of multiple competing httpd installations?

check php config

also probably relevant, if you are seeing the PHP module in some situations but not others, it could be valuable to use phpinfo() to see what php config is happening in the two situations. make a script in your webroot like:

<?php echo phpinfo(); ?>

and see what that turns up in each case. perhaps your environment is somehow causing different php.ini to be used?