I have a CentOS 5.x server running Mono 2.8.1 and mod_mono 2.8 with apache2.
Every time I deploy a site from visual studio 2010 to my server by ftp, and navigate to the site, I get a 404 not found error page.
Sites in other subdomains (virtual hosts) are not affected.
Performing a restart of httpd using /etc/init.d/httpd restart fixes the problem, and I can view my ASP site again. Obviously restarting the entire httpd process is less than adequate.
My guess is that this is similar to application domains in IIS. Is there a way to 'recycle' and app domain in mod_mono? Can I set this to happen on deployment?
You should be able to do /etc/init.d/httpd reload to force Apache to re-read its files from /etc/apache without it having to restart.
We have a process that attempts to download a hosted URL every minute, and if it returns 404, we kill -9 mod_mono. That should be enough, you shouldn't need to touch Apache.
Related
I am developing an ASP.NET application and deploying to an IIS 7 server via WebDeploy. This is a single server (no web farm or anything like this). I've been using the same setup for two years with no problems. Since last night, the server seems to be "stuck" on the last version of the web that I deployed before dinner. I deployed a couple of new versions today, but the server keeps serving the old pages.
I have triple checked this. When I log into the server via RDP and I open a specific ASPX file, I can see that it's the new version I've just deployed, so the server is actually storing the new versions. However, when I visit the web site over HTTP from my computer, I get the old version of the file.
I have restarted the server (the whole machine, not just IIS). I have disabled the IIS cache. I have disabled the compression cache. I have tried from multiple client computers, including one from which I had never ever visited this site (so no client cache may exist). But nothing worked.
I am aware that similar issues have been reported, and I have read some posts about it. But I seem to have exhausted all possible checks. Any ideas on how to proceed? Thanks.
After much struggling, I managed to solve this issue. I deleted the whole web site from the server, and I deployed it from a computer other than my usual development machine. This fixed the issue.
However, I am still baffled at why this happened. It must have been a glitch with WebDeploy and/or IIS.
I have configured reverse proxy to kestrel with nginx. When I redeploy the new DLLs using a bash script the site is not getting updated. I can see only the old site. When I try to kill dotnet process also it doesn't work. Even I tried restarting nginx, still no luck. I have to restart the server(linux) to see the changes. Why is it happening?
I want kestrel to detect changes when I update the files and automatically restart itself (or do something to publish the new site). Is there any other way to do it?
I have installed Web Deploy 3.5 on Windows Server 2008 R2 and tried to run remote publish web application through visual studio 2012. However, I got the error - Destination Not Reachable.
I read some post and checked below and still got no luck.
Firewall was off
Both Web Management Service and Web Deployment Agent Service were restarted and running
Tried to open https://[server]:8172/msDeploy.axd in a browser and it is reachable. (Use default 8172)
Tried to use http://[server]/MsDeployAgentService and it is working with Admin username/password.
Did I miss anything? Thanks.
Maybe same issue as in https://stackoverflow.com/questions/16708021/msdeploy-wmsvc-not-working ?
It appears you have to activate the web management service first and
then install web deploy and i'd done it the other way round. I
uninstalled WebDeploy and re-installed it, restarted the server and
its working
I also met the same problem. When installing WebDeploy, do not choose classic installation, but choose complete installation.
If you messed with SSL certificates this could be one of the causes as well:
https://serverfault.com/questions/613634/could-not-connect-to-remote-computer-web-deploy-error-destination-not-reachable#answer-812712
In Visual Studio 2012 RC when I try to validate a Web Deploy connection I get this error message:
ERROR_DESTINATION_NOT_REACHABLE
The required Web Management Service is started on the server and Web Deploy 3.0 RC is installed.
Then using Remote Desktop Connection I log on the server and go check IIS logs located at C:\inetpub\logs\LogFiles\W3SVC1. There I can see my attempts to validate the connection because they contain my IP address:
2012-07-13 20:58:49 185.201.117.17 HEAD /msdeploy.axd site=Default%20Web%20Site 8172 - 189.10.32.194 - 404 0 2 78
It's giving me a 404.
After trying to get this working for almost 6 hours now (reading a lot of material including this great Troubleshooting guide by IIS team titled Troubleshooting Web Deploy problems with Visual Studio and this related question Visual Studio 2010 Web deployment task failed) I decided to ask for help here and see if anyone has a clue about what can be the problem... Do you know what's causing this 404 error?
If you need any more info, just ask me and I'll provide it... :)
Edit 1
Yesterday I also tried the following msdeploy command on my local machine to list the the contents of a folder called test on the server [ and it worked as expected ]:
C:\Program Files\IIS\Microsoft Web Deploy V3>msdeploy -verb:dump -source:content
path=c:\test,computerName=xxxxxxxxxx.publiccloud.com.br,username=User,password=Password
Info: Using ID 'a246a13c-7777-4226-964c-fe9934c60b77' for connections to the rem
ote server.
MSDeploy.contentPath
c:\test
c:\test
c:\test\test.txt
Edit 2
After a lot of install/reinstall operations I finally got to a point where Windows Server 2008 is returning a 503 HTTP error when I try to publish the web site using VS 2012 RC or even msdeploy in the command line.
Looks like the best thing to do now is to do a clean install of Windows Server 2008 since I got a messed up VM server image to work with. Hope it'll do the trick.
Just for the record, this is the msdeploy command VS 2012 tries to execute. I did a copy/paste and tried it with msdeploy in the command line:
C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe -source:manifest='E:\SISPEC\SISPEC\obj\Release\Package\SISPEC.SourceManifest.xml' -dest:auto,ComputerName="https://xxxxxxxxxx.publiccloud.com.br:8172/msdeploy.axd?site=Default%20Web%20Site",UserName='UserName',Password='Password',IncludeAcls='False',AuthType='Basic' -verb:sync -enableRule:DoNotDeleteRule -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"E:\SISPEC\SISPEC\obj\Release\Package\SISPEC.Publish.Parameters.xml" -retryAttempts=2
just to get the same 503 Server Unavailable message.
Edit 3
This question was cross-posted at the IIS Web Deployment Tool (MS Deploy) forum here.
Fyi - I too was getting the 404 errors. It turned out that I had to download the full package and install everything.
http://www.iis.net/downloads/microsoft/web-deploy#additionalDownloads
I had this same error (ERROR_DESTINATION_NOT_REACHABLE). I was able to fix the issue by opening port 8172.
I then ran into the error: ERR_COULD_NOT_CONNECT_TO_REMOVESVC which I was able to resolve by installing every component of Web Deploy 3.0. It was trying to hit /MSDEPLOYAGENTSERVICE which by default isn't installed by the Web Deploy 3.0 installer.
I had to manually add the Deployment Handler. In IIS Manager, with the server selected, choose "IIS|Handler Mappings|Add Managed Handler...".
Request path: msdeploy.axd
Type: Microsoft.Web.Deployment.DeploymentAgentHandler,..., Version=9...
Name: Web Deploy Whatever
In my case, the default certificate issued for WMSVC was not issued for the machine-name. My Solution was to:
Issue a certificate for the machine name from my domain CA. This could be self-signed if you're willing to trust the certificate.
Install that certificate under the Personal certificate store
stop the web management service
change the certificate to my properly issued certificate
restart the service.
Did you check your handlers? You can test this by creating an HTML page on the same folder and trying to access that HTML. If you can, then go check that your site has the necessary handlers. Also, make sure your DNS record are pointing to the correct IP address.
First I tried just Repair install of Web Deploy 3.0 and not worked. Removing and installing solved my issue.
In my case I had both Web Deploy 2.0 and 3.0 on server machine.
Removing both and installing just 3.0 solved my issue.
Ensure Web Management Service is started.
I deleted SSL certificate and the service stopped working.
If all previous indications fail, and if you are using an Azure virtual machine, where the endpoint for 8172 is open, I have solved it deleting the endpoint and opening it again. I believe the first time I have selected using Floating IP Enabled, and that did not work. Just create the endpoint again, select disable floating ip and done!
alt text http://img822.imageshack.us/img822/2488/79392512.jpg
I shared maximum permissions there and there nothing in the log. I can't understand where this error comes from.
One of the reason that this may happens is because of crash of iis Admin 5.1. This happens a lot especial if you programming and make difficult thinks, or just a bad loop on your program can make this happens.
How to solve this.
on your website properties on Connections UNCHECK http Keep-Alives Enable.
restart the IIS Admin (and not only the "world wide web publishing") when you have problems.
Use the Process Explorer and check the iis admin and the www service that is running and not stack.
If any of this services has stack, then kill it from Process Explorer and then make IIS Admin restart.
When you restart IIS Admin, then the www is restarting also, but if fails to restart for sure you need to kill it with Process Explorer.
Hope this helps.
I seen usually with the mix of .Net versions deployed in IIS (ASP.Net).
Just ensure one is there.
if you have later versions of IIS then you can segregate different versions with the different worker process.
Hope it gives you some clue..