A question we periodically receive or hear about is: “What exactly is this ‘HTTP Error 503. The service is unavailable.’ error being thrown and why is it causing my site to go offline?”
This error is being thrown by Microsoft Internet Information Services (or IIS for short) and occurs when the application pool for the site in question is not able to work as expected (could be stopped or crashed).
So what is an application pool and why isn’t it working as expected:
Application Pool - An application pool is the IIS worker process that contains the configuration and application specific settings for the site(s) using this application pool. In most cases (as in our default setup for shared & vps services) each individual website created on the server has its own IIS application pool so that no single site is sharing settings with another site it’s not affiliated with.
A site having it’s own application pool provides extra security to that site and also prevents another site from crashing it’s shared application pool. If two sites share an application pool and one site causes the application to crash… then they would both go down… hence another good reason to keep each site using it’s own application pool.
-So why isn’t the application working as expected?-
The reason why the application pool isn’t working as expected can be a little more tricky. Normally you have to open the servers “Event Viewer” and dig through the logs to figure out why the application pool crashed. You would need to know the time that the application pool crashed in order to look through the logs for that time period.
In most cases we recommend doing the following:
A) If using our custom built WCP control panel login and click on the “IIS Settings” icon and then choose the “Advanced” tab. Once done click on the “Recycle” button to recycle the application pool. In other words this will attempt to re-start the application pool for the website.
B) If on the server directly via RDP then open IIS Manager and expand the server node, then choose “Application Pools”. Then find the application pool that is assigned to the site in question (FYI: If application is stopped you should see a stop icon over the application pool) and right click and choose “Start” or “Recycle”.
If the site starts back up then that is great! It sounds like the site may have consumed to much memory, ran across to many application errors, etc… the possibilities are endless and only the Event Viewer would be able to give a real clear truth as to why this occurred.
In most cases, however, the application pool crashes again immediately. Don’t allow this to get you frustrated though… because what this means is Event Viewer should now have a brand new log entry that can give you the information that you need in order to properly troubleshoot.
-
To start the troubleshooting process now that we’ve attempted a restart of the application pool and got an immediate crash, open Event Viewer on the server.
Note: To open Event Viewer you can run the command “
eventvwr.msc” from command prompt (CMD). You can also navigate on the server to “Windows > Administrative Tools > Event Viewer”.
-
Expand “Windows Logs” in Event Viewer and select the tree item for “Application” to view the application logs. Make sure to also review the “System” & “Security” logs as well, as depending on the cause of the crash the report may be within one of those sections instead.
-
I recommend that you select the “Filter Current Log…” and limit the errors shown to just the actual errors, then you can use the Find option in Event Viewer to search for the application pool name.
As mentioned above there are countless reasons as to what can cause an application pool to stop / crash. We’ll outline a few commonly seen causes below:
-
Possibility 1: Permissions set incorrect for site or application pool - In order for a site in IIS to work properly the site must be able to authenticate with elevated permissions on the directory that the site is loading from. For example sites automatically created via the custom built WCP control panel normally have a anonymous user created for each domain to use to authenticate. These users usually take the form of the domain and append _web to the user. For example if the domain is servermanagementco.com then the user might be named something like ‘servermanagementco_web’.
This user should have proper Read, Write, Execute, & Modify permissions on the directory that this site in IIS is assigned. For example C:\home\servermanagementco.com\wwwroot might be the directory our example site is pointing to. This folder should have the permissions specified above for our anonymous user.
In IIS we must also specify this user as well by navigating to “IIS > Sites > [site in question] > IIS > Authentication” (expand IIS server node, select ‘Sites’ and then double click the site in question and choose ‘Authentication’ under the IIS section). Click on the “Anonymous Authentication” option from the list and choose “Edit” from the right-side menu. You can then enter in the username and password for the web user.
Note: If using our WCP control panel then this is already setup by default properly with the correct permissions so you should not have to make any changes to the Site Identity (permissions) values.
-
Possibility 2: Too many errors / failures within your application - A feature added in IIS 7 that I want to talk about is Rapid Fail Protection. No, rapid fail protection isn’t the root cause of the issues… however your sites application pool might be in the “Stopped” state because of this feature. In the case of an application crash, IIS will attempt to restart the application pool. Application crashes can and will happen… however if too many happen within a certain amount of time ( 5 within a 5 minute interval ) then “Rapid Failure Protection” kicks in and places the application pool in the Stopped state.
We always recommend to our clients that they disable this feature by:
-
Open IIS Manager on the server.
-
Expand the server node, then choose “Application Pools”.
-
Find the application pool your site is using and select it, then click “Advanced Settings” from the right-side menu.
-
A dialog will appear, scroll down in this dialog and find the section for “Rapid-Fail Protection”. Change the state for enabled to False and then click the OK button to save the changes to the application pool.
You should now be able to go worry-free from the site crashing randomly again with this 503 error if caused by Rapid-Fail Protection. If you ever see this error on occasion, but not consistently… then it’s most likely caused by Rapid-Fail Protection.
-
-
Possibility 3: Application Pool Memory Exhaustion - If using our custom built WCP control panel then this most likely is not the cause of these errors, as we do not limit the amount of virtual memory that the application pools are allowed to use (unless on our shared environment). However still, I’d like to mention that this is a possibility. The Application Pool has a threshold of allowed memory it’s allowed to use before the application pool recycles. Now… this is only a recycle and isn’t stopping the application pool. However if the site is having extremely high load (or you have custom memory limit set very low) then the Rapid-Fail Protection we talked about above could kick in and stop the application pool. This isn’t likely, especially if you are using our default environment / control panel, however good information to still note.
Note: The possibilities don’t end after the three mentioned above… and you should investigate event viewer as mentioned in the section above to get a good clear understanding as to why the sites application pool is not working as expected and instead crashing.
If needing our support team to further research these errors please create a ticket with the necessary steps to replicate the error (URL you are receiving the error on) as well as any other information that might be helpful to the technicians working on your ticket.