Disable kudu for the running web app.
Why? Kudu is consuming the CPU periodically and I want to stop that.
So far I have tried to Kill the process by clicking on Properties >> Kill button. but this process gets start again.
You can use below settings in Application settings.
When separation enabled (the default), the main site and scm site run in different sandboxes.
WEBSITE_DISABLE_SCM_SEPARATION=true
Then you can check Process Explorer.
Offical Doc:
Use the same process for the user site and the scm site
I've created a Linux App Service running .NET Core 2.2 on Azure. When I go to the deployment center and choose Azure-Repos/ Azure-Pipelines as the source control and then select my MVC Core repo, i'm required to enter a Startup Command, but deleting the command afterwards in the App Service's Configuration - General-Settings doesn't actually prevent the website from running?
Edit:
Actually, if I don't delete the Start-up command after deployment my app wouldn't run!
Well yes, AFAIK, it is true that the Startup command should be optional in the Deployment Center configuration blade, like it is in the Azure App Service Deploy task, unless it's needed for some other specific reason.
I shall check with our internal teams about this and get back with more details as I have them. Thanks for the question!
Update:
#jcmontx We have created a workitem to track and fix this. Please note that there are some other high priority changes planned for Linux Web App continuous delivery which will have effect on how startup command is handled. This means we will have first wait for these to complete before processing the requested change. Thanks for your patience!
I had the same problem. The only solution I found to this was to:
Add a random comment as Startup Command (your build may fail the first time) when setting up the Pipeline in the Deployment Center.
Then go to Azure Pipelines -> Releases -> Select YourPipeline -> Edit -> Tasks -> Select "Deploy Azure App Service"
Scroll down the options and you'll find "Startup command"
Remove your previous input (step 1)
Save
We have several Azure app services live and I've ran into a consistent problem when restarting any of them.
We've right-click -> Published from Visual Studio upto an existing instance of an App Service which brings it online and functional immediately, we can update and republish new code without a problem, but restarting to app service from Azure Portal doesn't launch dotnet.exe.
When restarting or stopping/starting, the thread count instantly drops to 0 and continues to do nothing.
I have to manually publish from VS again to reboot dotnet.exe.
I can see that dotnet.exe isn't an active process via Kudu -> Process Explorer, and manually publishing up to the App Service and then refreshing the Process Explorer list again shows that dotnet.exe is now an active process and the App Service begins to function as expected.
Is there a way to prevent this, or at the very least debug why it's happening?
As it turns out this is being caused by silent failures, outside of error handling I'd put in place. IIS would spin up the associated processes but dotnet would throw and error and "silently" die.
I use quotes because I'd failed to utilise Azure's indepth logging, which hid the error message from plain view until switched on.
For some basic debugging steps:
Open up your Kudu console (Advanced Tools -> Go -> Debug Console) and navigate to LogFiles, open up eventlog.xml, the latest events are listed at the bottom.
Run dotnet myDll.dll against your debug folder locally, where myDll.dll is the main dll in your project. This will typically throw the error causing dotnet to exit out, which wasn't obvious at design time.
Ensure that your server-side appsettings.json (or the associated appsettings.[development/release].json contains the connection strings you're attempting to access.
The errors that were occuring we'ren't due to design-time bugs, it generally fell over when trying to access run-time resources (such as appsettings).
I just stopped an Application Pool in IIS. When trying to start it, IIS complains that,
The service cannot accept control messages at this time. (Exception from HRESULT: 0x80080425).
What gives? Whence did this error come?
Looking at the Event Viewer > System shows these warnings:
A worker process '1456' serving application pool 'MyAppPool' failed to stop a listener channel for protocol 'http' in the allotted time. The data field contains the error number.
A process serving application pool 'MyAppPool' suffered a fatal communication error with the Windows Process Activation Service. The process id was '10592'. The data field contains the error number.
A process serving application pool 'MyAppPool' exceeded time limits during shut down. The process id was '10516'.
This resolved itself after about 5-minutes, at which point we tried to restart the website, and received:
The World Wide Web Publish Service (W3SVC) is stopped. Web sites cannot be started unless the World Wide Web Publishing Service (W3SVC) is running.
So, we started the W3SVC service, and then we could start our website.
This helped me: just wait about a minute or two.
Wait a few minutes, then retry your operation.
Ref: https://msdn.microsoft.com/en-us/library/ms833805.aspx
The error message could result due to the following reason:
The service associated with Credential Manager does not start.
Some files associated with the application have gone corrupt.
Please follow the steps mentioned below to resolve the issue:
Method 1:
Click on the “Start”
In the text box that reads “Search Program and Files” type “Services”
Right click on “Services” and select “Run as Administrator”
In the Services Window, look for Credential Manager Service and “Stop” it.
Restart the computer and “Start” the Credential Manager Service and set it to “Automatic”.
Restart the computer and it should work fine.
Method 2:
1. Run System File Checker. Refer to the link mentioned below for additional information:
http://support.microsoft.com/kb/929833
In my case, the VS debugger was attached to the w3wp process. After detaching the debugger, I was able to restart the Application Pool
I stopped the IIS Worker Process (in task manager), and then started the IIS again.
It worked.
I killed related w3wp.exe (on a friends' advise) at task manager and it worked.
Note: Use at your own risk. Be careful picking which one to kill.
Restarting the machine worked for me but not every time.
If you are really stuck on this then follow below steps
Open Task Manager
A window will open. Click on Details tab.
Search for the process name you wanted to restart/stop.
Select process, right click on it, select End task option.
A confirmation dialog box will appear. Click on End process button.
Now try to restart your service from Services.msc window.
I forgot I had mine attached to Visual Studio debugger. Be sure to disconnect from there, and then wait a moment. Otherwise killing the process viewing the PID from the Worker Processes functionality of IIS manager will work too.
Restarting the IIS windows service (World Wide Web Publishing Service) and then starting the application pool has worked for me. However, as the top answer suggests it may have just been the waiting that caused it to subsequently work.
I had this issue recently,
Problem statement:
Mine was a windows service that I run locally by attaching VS debugger. When I stop debugging and try to restart/stop the service (under services.msc) I used to get the mentioned error.
Solution:
Open up Task manager.
Search for the service (based on the exe name and not service name, for those that are different).
Kill the service.
On doing the above the service is stopped.
Being impatient, I created a new App Pool with the same settings and used that.
I kept having this problem whenever I tried to start an app pool more than once. Rather than rebooting, I simply run the Application Information Service. (Note: This service is set to run manually on my system, which may be the reason for the problem.) From its description, it seems obvious that it is somehow involved:
Facilitates the running of interactive applications with additional administrative privileges. If this service is stopped, users will be unable to launch applications with the additional administrative privileges they may require to perform desired user tasks.
Presumably, IIS manager (as well as most other processes running as an administrator) does not maintain admin privileges throughout the life of the process, but instead request admin rights from the Application Information service on a case-by-case basis.
Source: social.technech.microsoft.com
Visual Studio 2013 update 3. I have deployed several Webjobs to Azure, both manually (upload a bundle via the portal) and also published directly from Visual Studio. The webjobs I am testing with are set to run "Continuous" and have code that runs inside a while(true) {} loop; so the process never ends. The webjobs are functioning properly and I see their runtime output in the Webjobs dashboard log output screen.
I've enabled remote debugging on the website. When I select Debug, Attach to process, the webjob process names never show on the list. All I see are the remote debugger processes and w3wp.exe.
Ideas?
Instead of attaching to SITENAME.azurewebsites.net, try to attach to SITENAME.scm.azurewebsites.net. Use same credentials as for the regular debugging connection. WebJobs run under a different context (Kudu), hence the different endpoint.