I'm adding a simple startup task to my Azure Cloud Service project. The script ensures the Cloud Service does not time out on the server (see link). When I add the task to my ServiceDefinition.csdef file, my project doesn't run; it hangs forever and reads "Starting the roles for the application in the Microsoft Azure compute emulator..." in the status bar of VS. Here is my ServiceDefinition.csdef:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="DryrunCloud" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6">
<WebRole name="MyCloud" vmsize="Small">
<Startup>
<Task commandLine="Startup.cmd" executionContext="limited" taskType="simple"></Task>
</Startup>
<Sites>
...
The Startup.cmd file (placed in bin folder of web role project):
REM *** Prevent the IIS app pools from shutting down due to being idle.
%windir%\system32\inetsrv\appcmd set config -section:applicationPools - applicationPoolDefaults.processModel.idleTimeout:00:00:00
REM *** Prevent IIS app pool recycles from recycling on the default schedule of 1740 minutes (29 hours).
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.recycling.periodicRestart.time:00:00:00
Any ideas?
This link ultimately helped me. When you create the cmd file in VS, for some reason it doesn't work. You have to create it outside of your solution and then add it to your project.
Related
Jenkins was up and running for months without issue, as a windows service.
I did some Jenkins updates (copied a newer/later .war file to the .jenkins folder) and some windows updates also occurred. The version that I have is Jenkins 2.263.3.
I did a lot of trolling through the documentation and other StackOverflow tickets and found out that the JENKINS_HOME environmental variable was missing. I added this.
Here is what my investigation reveals.
The Java environment variable is set - see below:
C:\>java -version
java version "1.8.0_171"
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
JENKINS_HOME environmental variable is set - see below:
C:\>echo %JENKINS_HOME%
C:\Users\XXXXX\.jenkins
The Installation was under user XXXXX and the service account Log On was configured accordingly
I do not have another application using port 8080 - I checked this with sys internals.
My jenkins.xml looks like this:
<service>
<id>jenkins</id>
<name>Jenkins</name>
<description>This service runs Jenkins automation server.</description>
<env name="JENKINS_HOME" value="%BASE%"/>
<!--
if you'd like to run Jenkins with a specific version of Java, specify a full path to java.exe.
The following value assumes that you have java in your PATH.
-->
<executable>java</executable>
<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8080 --webroot="%BASE%\war"</arguments>
<!--
interactive flag causes the empty black Java window to be displayed.
I'm still debugging this.
<interactive />
-->
<logmode>rotate</logmode>
<onfailure action="restart" />
<!--
In the case WinSW gets terminated and leaks the process, we want to abort
these runaway JAR processes on startup to prevent corruption of JENKINS_HOME.
So this extension is enabled by default.
-->
<extensions>
<!-- This is a sample configuration for the RunawayProcessKiller extension. -->
<extension enabled="true"
className="winsw.Plugins.RunawayProcessKiller.RunawayProcessKillerExtension"
id="killOnStartup">
<pidfile>%BASE%\jenkins.pid</pidfile>
<stopTimeout>10000</stopTimeout>
<stopParentFirst>false</stopParentFirst>
</extension>
</extensions>
<!-- See the referenced examples for more options -->
</service>
I can start Jenkins from the command line as follows:
java -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "C:\Users\XXXXX\.jenkins\jenkins.war" --httpPort=8080 --webroot="C:\Users\XXXXX\.jenkins\war
If I try start it from the Serice Manager I get this error - System.BadImageFormatException
One last thing, once I start Jenkins from the command line, and login to the the application, I note the following Jenkins System log:
Feb 17, 2021 10:29:31 AM INFO hudson.WebAppMain$3 run
Jenkins is fully up and running
Feb 17, 2021 10:29:57 AM WARNING hudson.lifecycle.WindowsServiceLifecycle getBaseDir
Could not find environment variable 'BASE' for Jenkins base directory. Falling back to JENKINS_HOME
Any suggestions how to get the service to start via the Service Manager?
The service is starting and stopping without issue.
The problem I suspect was that the original install of Jenkins was very old, and I presume that it may have been a 32-bit application at the time. The current updates seem to 64-bit apps. Since the original install, Jenkins was updated - with changes spanning several major releases from the original install (.war file updates). The jenkins.exe file - that starts the service was never updated.
The error message 'System.BadImageFormatException' after much research indicated that the issue was related to compatibility difference between 32/64 bit executable. I presume it was expecting a 64-bit executable but was getting a 32-bit exe.
To solve this problem I installed the latest version of Jenkins on my local PC.
On the Server I backed up the files:
jenkins.exe
jenkins.exe.config
I then stopped Jenkins on the Server, where the Service was not Starting (from the terminal window with Ctrl+D).
I then replaced these 2 files on the server with the latest files from my local installation.
Service started the first time.
I have been trying to install Jenkins on tomcat9 but when I go for the first time on http://myip:8080/jenkins to finish the setup; I have the the following error:
java.io.IOException: Read-only file system
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:2026)
at hudson.util.AtomicFileWriter.<init>(AtomicFileWriter.java:142)
Caused: java.io.IOException: Failed to create a temporary file in /var/lib/jenkins
at hudson.util.AtomicFileWriter.<init>(AtomicFileWriter.java:144)
at hudson.util.AtomicFileWriter.<init>(AtomicFileWriter.java:109)
at hudson.util.AtomicFileWriter.<init>(AtomicFileWriter.java:84)
at hudson.util.AtomicFileWriter.<init>(AtomicFileWriter.java:74)
at hudson.util.TextFile.write(TextFile.java:116)
at jenkins.model.Jenkins.<init>(Jenkins.java:910)
at hudson.model.Hudson.<init>(Hudson.java:85)
at hudson.model.Hudson.<init>(Hudson.java:81)
at hudson.WebAppMain$3.run(WebAppMain.java:262)
Caused: hudson.util.HudsonFailedToLoad
at hudson.WebAppMain$3.run(WebAppMain.java:279)
First: Tomcat9 is working well, I can access it locally or remortly
I have created /var/lib/jenkins which is owned by jenkins (unix user I have created), I have even setup the permission to 777.
Second: if i run the war in command line 'java -jar jankins.war" ( I have exported JENKINS_HOME=/var/lib/jenkins before), then jenkins works correctly. So the war is not corrupt.
third: on tomcat, I have modified the context.xml to set up JENKINS_HOME to /var/lib/jenkins, it is working as you can see the above error (5th line).
Then in context.xml I have tried to setup JENKINS_USER to several different users (jenkins, tomcat, root etc) , I tried different ownership for /var/lib/jenkins (and group as well).
here is my context.xml:
<Context>
<Environment name="JENKINS_HOME" value="/var/lib/jenkins" type="java.lang.String" />
<Environment name="JENKINS_USER" value="jenkins" type="java.lang.String" />
<!-- Default set of monitored resources. If one of these changes, the -->
<!-- web application will be reloaded. -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>WEB-INF/tomcat-web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!--
<Manager pathname="" />
-->
</Context>
But nothing is working, it looks like JENKINS_USER is not taken into account and/or whatever I do the directory is read-only ....
NB: as I have read there might be some issues with JDK version, so I have tried with open-jdk-11 (at the beginning) then with open-jdk-8
Has anyone face this issue ?
If you run tomcat9 from the Ubuntu repositories, it will run as the unix user tomcat. Providing access to a user jenkins won't give permissions to tomcat. And just defining arbitrary environment variables (JENKINS_HOME, JENKINS_USER) won't make a web application magically change its identity.
All web applications in tomcat run as the same user, and that's the one that you need to provide access to.
Also, notice that Debian's Tomcat runs in a sandboxed environment (see this answer to a relevant question), so you'll need to work on the sandbox environment in addition to the owner of the files/process.
I'm trying to configure a build and release pipeline in VSTS so that I can push a build to a variety of environments. To accomplish this, I'm leveraging the parameters.xml file for MSDeploy, as well as using a Tokenizer task to overwrite the tokens that are set in the SetParameters.xml file after.
When I deploy to the site, it does reach the destination computer and deploy there, but the path is incorrect. Instead of copying to the virtual directory of the web application that I've specified in parameters.xml, it seems to take the path that is in the package and copies that (so, C:\agent_work...).
I know that the tokenizer and at least part of parameters.xml and SetParameters.xml is working and correctly transforming connection strings, as the generated web.config does have those values correct, but the IIS Web Application Name parameter doesn't seem to be working.
I did get this to work if I create my own publish profile and hard code the site name in the DeployIisAppPath and use that to package instead. This isn't ideal, though, as I want to have the site name as a parameter.
Here are all relevant files. Let me know if you need more info. Thanks so much in advance!
parameters.xml
<parameters>
<parameter name="IIS Web Application Name"
description="Please specify the IIS Web Application Name"
defaultValue="__IISWebApplicationName__">
<parameterentry kind="ProviderPath"
scope="IisApp"
match="#defaultValue">
</parameterentry>
</parameter>
</parameters>
VS Solution Build Task Arguments
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation=$(build.artifactstagingdirectory)
/p:AllowUntrustedCertificate=true
/p:IncludeSetAclProviderOnDestination=False
/p:DeployOnBuild=true
/p:AllowUntrustedCertificate=true
/p:WebPublishMethod=Package
/p:SkipInvalidConfigurations=true
/p:DisableAllVSGeneratedMSDeployParameter=true
SetParameters.xml after packaging
<?xml version="1.0" encoding="utf-8"?>
<parameters>
<setParameter name="IIS Web Application Name" value="__IISWebApplicationName__" />
</parameters>
Release Task Environment Variable Configuration
Name = IISWebApplicationName
Value = Site Name
MSDeploy Configuration
Destination Provider: auto
Destination Computer: https://{server}:8172/msdeploy.axd?site=$(IISWebApplicationName)
MSDeploy Commmand
msdeploy.exe -verb:sync -source:package='C:\agent\_work\r4\a\{buildName}\drop\{packageName}' -dest:auto,computerName='https://{server}:8172/msdeploy.axd?site=Site Name',userName='xxx',password='xxx',authType='basic',includeAcls='False' -allowUntrusted -setParamFile=C:\path\to\param\file -verbose
You can deploy web app to IIS by using IIS Web App Deploy task, then you just need to specify Website name with variable directly.
Configure Deployment group
Edit release definition
Add Run on deployment group
Add IIS Web App Deploy task and specify website name
On the other hand, the WinRM: IIS Web App Deployment task in IIS Web App Deployment Using WinRM extension works fine two (Do not need to configure deployment group.)
I'm using the Grails stack on Heroku to deploy an app. I'd like to be able to serve my app with a root of myapp.herokuapp.com/xyz as opposed to myapp.herokuapp.com, in the same way I'm able to serve from root of localhost:8080/xyz in development. I've tried adding a grails.app.context in Config.groovy like so:
environments {
production {
grails.app.context = "/xyz"
}
}
But it doesn't seem to have an effect in deployment. Do I have to configure something with Heroku? Any ideas?
It looks like you have to add a jetty-web.xml file to the WEB-INF directory to set the context path:
<?xml version="1.0" encoding="UTF-8"?>
<!-- File: web-app/WEB-INF/jetty-web.xml -->
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="contextPath">/xyz</Set>
</Configure>
If this helps proper credit goes to this site, which was linked from an article on Grails and Heroku by Tomas Lin.
I don't think you can set context path with the current Grails build pack. If you feel like it, you can fork the build pack and hack it to support setting context (see build pack doc for more info on build packs).
Another option is to build your Grails app locally into a WAR file and deploy the WAR file using WAR deployment. The WAR deployment process will use the webapp-runner utility to run your app with Tomcat and it supports configuring the context path. Here's the help output for webapp-runner 7.0.22.3 (what I happened to have installed, might be slightly out of date):
Tomcat Runner runs a Java web application that is represented as an exploded war in a Tomcat container
Usage: java -jar tomcat-runner.jar [arguments...] path/to/webapp
Arguments:
--session-timeout The number of minutes of inactivity before a user's session is timed out
--port The port that the server will accept http requests on
--context_xml The parth to the context xml to use
--path context path (default is /)
--session_manager session store to use (valid options are 'memcache')
--session_manager_operation_timeoutoperation timeout for the memcached session manager. (default is 5000ms)
--session_manager_locking_modeSession locking mode for use with memcache session store. (default is all)
--session_manager_ignore_patternRequest pattern to not track sessions for. Valid only with memcache session store. (default is '.*\.(png|gif|jpg|css|js)$'
As explained in the WAR deploy doc, you can set webapp-runner options for your webapp using the WEBAPP_RUNNER_OPTS config var.
in my war's META-INF/context.xml I have:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/foobar" docBase="my-long-war-name"/>
I deploy my war to the webapps/ directory and I confirm that my contex.xml is in %CATALINA_HOME%\conf\Catalina\localhost with the name my-long-war-name.xml
Now, instead of accessing my REST service through http:/ /localhost:8080/my-long-war-name/contacts/data tomcat should allow http:/ /localhost:8080/foobar/contacts/data
but I can only access my service through the former URL. It's as if it completely ignores the path given above for my web app. I even tried omitting docBase and that didn't work either.
why doesn't this work?! it's supposed to be so basic!
I don't see why you need the <Context>. I never touch that when deploying to Tomcat, and everything works fine.
Why don't you just make the WAR name foobar, deploy it, and be done with it? You seem to be wedded to this idea in spite of the evidence to the contrary about how basic it is.