Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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).

share|improve this question
What version of CentOS? – sciurus Apr 24 '14 at 15:15
@sciurus 6.5 (Final) – svidgen Apr 24 '14 at 15:18
... I'm about to edit though. I just realized there are a few steps that may impact things. – svidgen Apr 24 '14 at 15:19

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?

share|improve this answer
Good ideas (+1) ... still trying to determine what the meaningful difference is between the environments the process is run in. Any idea what ENV differences might be relevant? – svidgen Apr 25 '14 at 14:03
if you are talking about the phpinfo() step, i would log the results to a file in each case and then diff the files to see what turns up. – J. Paulding Apr 25 '14 at 14:08

/etc/init.d/httpd does not call the httpd binary. When you execute service httpd start the deamon program is called to start httpd in the background with the specified pidfile along with options from /etc/sysconfig/httpd.

start() {
    echo -n $"Starting $prog: "
    LANG=$HTTPD_LANG daemon --pidfile=${pidfile} $httpd $OPTIONS
    [ $RETVAL = 0 ] && touch ${lockfile}
    return $RETVAL

Likewise, executing service httpd stop uses the killproc function that's sourced from /etc/rc.d/init.d/functions to stop httpd.

stop() {
    echo -n $"Stopping $prog: "
    killproc -p ${pidfile} -d ${STOP_TIMEOUT} $httpd
    [ $RETVAL = 0 ] && rm -f ${lockfile} ${pidfile}

Init scripts can be read like any other text file. If you want to know what they're doing just look for yourself.

BTW, it's recommended by Apache to use apachectl to control httpd. Several of the init scripts are written from templates and may not necessarily take the best practices from the developer into consideration.

You can edit /etc/init.d/httpd to suit your needs but make sure you fully understand what you're doing before you do it.

share|improve this answer
Good info (+1). I've been poking around the daemon function it executes; but haven't been able to identify what the important difference is. When I manually execute the "final" command it runs (/bin/bash -c 'ulimit -S -c 0 >/dev/null 2>&1 ; /usr/sbin/httpd'), it works properly. Is there something general in the file that could be running it with different permissions or restrictions? ... phpinfo() reports a different env; but I'm struggling to see which values would be relevant to the success of a single module loading ... Any further thoughts? – svidgen Apr 25 '14 at 14:01
@svidgen When httpd is started using daemon the -k start option isn't used which may be causing your problems. You can execute /usr/sbin/httpd without any options at all and it will start httpd, but that doesn't mean that it was started correctly. /bin/bash -c 'ulimit -S -c 0 >/dev/null 2>&1 ; /usr/sbin/httpd' by itself is just setting a soft limit of 0 for core dumps so that shouldn't affect loading modules. – Creek Apr 25 '14 at 15:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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