Oct 202010
 

OK if you’ve installed Apache on Windows of any flavour you’re used to the occasional weird thing happening and preventing it from working, one of the most annoying is the ubiquitous “Cannot open logs” error in the System event log.  This invariably means that something is listening on Port 80.  To prove this for yourself you can go to your run command and enter:

netstat -o -n -a | findstr 0.0:80

The last number here is the process ID using it.  This is most often IIS or other web relates service and is easy to resolve, but every so often (very often it would seem looking around on google) it appears to be PID 4 – which according to the Windows Task Manager is the NT Kernel and System.  Not very helpful given killing this will result in a blue screen of death.  Anyway tonight after much fiddling around I discovered that the thing that was hogging port 80 was nothing to do with IIS or web anything, it was SQL server reporting services.   I turned off anything that resembled a SQL server services and voila Apache started again, no need for a reboot which had hitherto been my only solution.  So problems with PID 4 listening to port 80?  Check your SQL services and turn them off!

Addendum to  PID 4 listening to port 8 – Apache cannot start

Thanks to Tauseef  below who has also mentioned that “A new service called “Web Deployment Agent Service” (MsDepSvc) can also trigger “System” with PID=4 to listen on port 80.”

Bharat below (thanks Bharat) has also contributed “Web Deployment Agent service was triggering “System” with Port id= 4 to use Port 80. I disabled it in Services, changed back to Port 80 in Apache config and bingo, Apache started working on its default port. Then I uninstalled Microsoft Web Deploy 2.0 to permanently remove this problem.

Sanoop says (Thanks!) – ‘For me the service “branch cache” had hold of port 80.’

 

 

Jan 202010
 

.htaccess problems and can be a real pain, especially if like me you only do things with the .htaccess file every now and then so aren’t completely comfortable with the syntax.  Last night when helping a friend and author of the excellent ExchangeWire (about tracking the nascent ad exchange and ad trading networks) switch a domain, I configured the .htaccess file using a standard format:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldomain.com$ [OR]
RewriteCond %{HTTP_HOST} ^www. oldomain.com$
RewriteRule ^(.*)$ “http\:\/\/www\.newdomain\.com\/$1″ [R=301,L]

I say “a” standard format because as anyone who has used .htaccess before knows, there are a few variations on this syntax that do the same thing.  Not thinking about it much I put this in the root .htaccess of the WordPress install, I tested the top domain, worked fine, but the pages themselves just kept redirecting to the the root, not the actual page.  My complete .htaccess file that was not redirecting properly:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldomain.com$ [OR]
RewriteCond %{HTTP_HOST} ^www. oldomain.com$
RewriteRule ^(.*)$ “http\:\/\/www\.newdomain\.com\/$1″ [R=301,L]

Ok so the clued up amongst you will realise the problem was caused because of the ordering of the commands I had put in the file, this is important. In terms of importance, the domain redirection had to happen first, so I needed to put it above the WordPress command otherwise the WordPress command hijacked the process and confused the primary redirect.  So, the lesson is be careful of the order you put things in and the potential conflicts that can occur as a result.  Keep the major redirects/rules at the top of the page (e.g. when you want to change domains) and the more detailed one(s) below for more consistency (such as WordPress redirects).