How to restart Apache on the Mac

Over the years, the command for restarting Apache has changed. E.g. here are some:

/etc/init.d/apache2 restart

rcapache2 restart

sudo service apache2 restart

sudo restart apache2

sudo apachectl restart

For even more options see:

I finally got fed up of having to work out which option I needed and wrote a simple Mac menu bar app called Mescalero (after the Apache tribe) that lets you restart the Apache web server using a simple GUI. It’s in Beta right now. Sign up to join as a beta user or to be notified once it is formally released here:


Building software is still way too difficult – the Avalanche effect

Here’s an example. I’m a pretty experienced web developer with 20 years under my belt however sometimes what should be a simple fix can take several hours to solve. I can’t imagine how painful it must be for a beginner. I call this problem the Avalanche effect. A simple task triggers off another two tasks which each trigger off another two tasks. Suddenly you’ve got a whole bunch of stuff to fix.

Here are some examples

A. I want to import some WordPress demo content. Should be super-easy right? You just go into the Admin and click Install Demos.

Here are the problems I encountered along the way:

1. PHP Time Limit:
30 – We recommend setting max execution time to at least 180.
To import classic demo content, 300 seconds of max execution time is required.

This is pretty standard. Normally you simply edit php.ini and restart your web server.

I’m using a Varying Vagrants Vagrant box in an effort to simplify some of my development tasks. However, the law of leaky abstractions strikes back.

You ssh in using:

vagrant ssh

Then you look around for the php.ini file. Turns out there are 3 versions of PHP installed (5.5, 5.6 and 7.0). Not only that but there are different types of PHP installed for each version (e.g. CLI, FPM). However, from past experience I’ve figure out it’s simply easiest to figure out which one your web browser is using by creating a phpinfo() script.

You make the change to the max_execution_time.

Then you try and restart the web server. Turns out this doesn’t work:

service apache restart

I’m aware that the way services are restarted has changed in recent years. So, I try them all:

/etc/init.d/apache2 restart


rcapache2 restart


sudo service apache2 restart


sudo restart apache2


sudo apachectl restart

None work.

For even more options see:

After much digging it turns out this particular Vagrant box uses nginx.

After all that, it turned out the execution time did not change as reported by phpinfo.

At this stage, I could understand how someone might think they’ve somehow got something wrong. After all, why did this not change?

Turns out, by scanning through phpinfo, that there are additional ini files loaded and one of those has the exact same setting which overrides the first!

By the way, I haven’t even mentioned how these beginners would already need to have got up to speed with concepts like sudo and vim. e.g. tricks like searching through files with vim or emacs.

Or knowing all the alternative paths that files might live at (e.g. web directories which could be in /Users/<your name>/public_sites on a Mac, or /var/www/html, or any of the dozens of other options.

Anyhow, after making a change to this second php.ini again, no change.

I checked for a .htaccess file. No sign.

I did a search through the entire web directory for max_execution_time. The only result I found was here:


If you didn’t know these were just sample configs and not read by Vagrant or Nginx you could waste valuable time messing around with those.

In the end I gave up using Vagrant and just set it all up locally – far easier. I hadn’t even started on the other problems that the Install Demos pane was reporting.


B. I upgrade PHPStorm. Should be trivial, right?

Here’s what happened.

  1. I upgrade PHPStorm. Done.
  2. Then I open up an old project which is listed in PHPStorm when I open it
  3. I update some code
  4. I find that, along with my updated code, I’ve got some new .idea files in my repo that say:

    Untracked files:

      (use “git add <file>…” to include in what will be committed)


  5. I’ve already experienced how these .idea files can mess up your git repo so I’ve already created a .gitignore file to avoid them ( ). I’m surprised that this wasn’t caught by it. Now I have to research what to do. I can:
    1. delete it (but the problem might surface again in the future)
    2. figure out why my .gitignore file did not catch it
    3. track it (but I shouldn’t have to track an IDEA copyright file)

So, a simple upgrade means I now need to spend half an hour figuring this problem out. For those wanting to know, here’s the answer.

Add this line to your .gitignore file:



Here’s another thing that happened during the upgrade. I get a message that goes:

The directory <some directory> is under Git, but is not registered in the Settings.

Add root  Configure  Ignore

Seeing as I’d set this up earlier, it’s super annoying that you have to do this all over again.

First of all, should I Add root or Configure? So, you go look these up and it all takes 10 or 15 minutes longer before you can even get started coding. I clicked Add root, the pane faded slightly and I ended up with no idea what had just happened. I had a slightly unsettling feeling that I had just introduced an upstream problem.