This command autostarts apache : sudo defaults write /System/Library/LaunchDaemons/org.apache.httpd Disabled -bool false

From this article: http://reviews.cnet.com/830...

thx man, you really saved me a lot of time!

To have the webserver running after a reboot just change the value from disabled to enabled in : /System/Library/LaunchDaemons/org.apache.httpd.plist

and to launch right away:
sudo launchctl load -w /System/Library/LaunchDaemons/org.apache.httpd.plist

Absolute bollocks that they kill it like that without notifying. Lately, I don't know, think Apple forgets who their prime users were, the ones who supported them through good and bad,

Dan,

Well, mine looks about the same (except I have 'AllowOverride None'), and it works. Don't know quite where to look next.

I had a test Apache server installed with PHP and MySql on OS X Lion, which was working fine, and recently upgraded to OS X Mountain Lion. The Apache server was not currently running when I upgraded. I was able to get Apache running again using the type of suggestions posted on this blog. I can access PHP from my "~username/Sites/" folder by entering "http://localhost/~username" with no problem. However, when I attempt to access "localhost" using "http://localhost" I receive the message "Forbidden You don't have permission to access / on this server." I am also having problems with my phpMyAdmin and I think it is related to this, as there is a similar error message. Does anyone have any suggestions why I am getting the permission access restriction message at 'root' but not at the Sites folder?

I'm just overly cautious, I guess. And, I'm primarily a Linux admin, where I always specify on-boot daemon launches in sysV init scripts. Having less familiarity with launchd, I just felt safer specifying the apachectl startup directly. Plus, what if somebody had stopped apachectl manually before the system restart? This verifies that it'll always start up in the desired state, which again hearkens back to my Linux heritage.

Lri is correct, above, about the launchctl command. However, that's actually exactly what the 'apachectl' script does. So, in any case, if you've started Apache with apachectl or with launchctl manually, it'll still be working through a clean reboot.

But what if it reboots uncleanly? In that case, it's better to use the existing plist than to build your own. To set this up, I added the following line to root's crontab (with sudo crontab -e):
@reboot /usr/sbin/apachectl restart

Now, Apache is always started on boot, and I didn't have to hack up my own plist. I use 'restart' because, if it's started already (by the persistence of the launchctl daemon), a 'start' command will cause a warning that httpd is already running. But 'restart' works without complaining whether Apache is already running or not.

After following your steps my virtual hosts still didn't come back up. I checked my apache file syntax and discovered the issue. It seems that before there was an /etc/httpd/ssl.key path. Now it looks like httpd has been removed, so the path is now just etc/ssl.key.

A lot of my sites run under a local SSL cert i setup, so when those couldn't be found, apache failed to load correctly.

To recap, if your hosts don't come up, issue this command:
sudo apachectl -t

You should see an error something like this:
Syntax error on line 99 of /private/etc/apache2/extra/httpd-ssl.conf:
SSLCertificateFile: file '/etc/httpd/ssl.key/my-custom-site.crt' does not exist or is empty

Open the file with the error (/private/etc/apache2/extra/httpd-ssl.conf) and modify the path by removing the "httpd/" from the path. There will most likely be two places where you will need to change that. I had several and just kept repeating the steps until all my ssl locations were updated. Hope this helps others.

Maybe helpful too:

check in httpd.conf if you are not by chance including both the httpd-vhosts.conf located in
/private/etc/apache2/other AND
/private/etc/apache2/extra

For me this was the big mistake.

Be sure to check the output of both apache:
apachectl -t AND
apachectl -S

The first keep on warning me about a fully qualified domain name, but things are working now...

I'm still not sure, but according to comments on other sites it would seem that the launchd plist that starts Apache is still there on clean installations of 10.8, and you don't have to make your own one.

launchctl load -w /System/Library/LaunchDaemons/org.apache.httpd.plist would start Apache and enable the launchd service that starts it automatically after logging out and back in.

To make http://localhost/~username/ work, you have to create /etc/apache2/users/username.conf and add a <Directory> directive like this:

<Directory "/Users/username/Sites/">
    Options Indexes MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

I did a test install of ML just to check this out after reading other comments on the web. Things turned out to be better than I'd been led to believe: "sudo apachectl start" told me it was already running, and when I directed Safari to http://localhost/, indeed it was running. I guess this was because I installed ML on top of a Lion system which had Web Sharing enabled, and the installer did the sensible (?) thing. Presumably, a clean install would have required the shenanigans described here and elsewhere.

I don't know if it's because I upgraded to 10.8, but Apache was already started automatically by /System/Library/LaunchDaemons/org.apache.httpd.plist.

/etc/apache2/users/username.conf was removed though, so I had to create it again to change the DocumentRoot of virtual hosts. Mine looks like this:

NameVirtualHost *:80

<Directory "/Users/username/Sites/">
    Options Indexes MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

<VirtualHost *:80>
    DocumentRoot "/Users/username/Sites/testsite/"
    ServerName testsite.dev
</VirtualHost>

The guy who makes VirtualHostX has made a handy preference pane to re-enable the web sharing option: http://clickontyler.com/blo...

The guy who makes VirtualHostX has made a handy preference pane to re-enable the web sharing option: http://clickontyler.com/blo...

Brett,

I'm surprised you would be doing this 'natively.' I would highly recommend using a VM to isolate your actual dev environment. Not only is it simply cleaner, it makes it much easier to get back up and running in the event of a system failure.

I remap my caps lock key to quicksilver using KeyRemap4MacBook & PCKeyboard Hack and after 10.8 it wasn't working, and I got it to work by following this information I found on the PCKeyboardHack Github page:

You can get PCKeyboardHack for 10.7 to work with Mountain Lion by using the 10.7 kext. I'm using a couple remappings and everything seems to work great.
These are the steps I followed to make it work:
1. Download and Install PCKeyboardHack for 10.7
2. Restart
3. Edit (as sudo): /Library/org.pqrs/PCKeyboardHack/scripts/kext.sh (see below)
4. Restart

/Library/org.pqrs/PCKeyboardHack/scripts/kext.sh:

!/bin/sh

PATH=/bin:/sbin:/usr/bin:/usr/sbin; export PATH

basedir="/Library/org.pqrs/PCKeyboardHack"
kextfile=''
uname=uname -r
case "${uname%%.*}" in
10)
kextfile="$basedir/PCKeyboardHack.10.6.kext"
;;
11)
kextfile="$basedir/PCKeyboardHack.10.7.kext"
;;
12)
kextfile="$basedir/PCKeyboardHack.10.7.kext" # Hack to use 10.7 kext in 10.8
;;
esac

if [ "x$kextfile" == 'x' ]; then
exit 1
fi

if [ "$1" == 'unload' ]; then
kextunload -b org.pqrs.driver.PCKeyboardHack
else
kextload "$kextfile"
fi

exit 0