Cannot start jenkins. giving below logs when try to restart but doesnt work -
-bash-3.2$ ./jenkins.sh start
Jenkins is currently stopped...
Starting Jenkins with command cd /eas/jenkins;/eas/jenkins/jenkins_jre/jre1.7.0_51/bin/java -Xms1024m -Xmx2048m - XX:MaxPermSize=512m -DJENKINS_HOME=/eas/jenkins/home -jar jenkins.war
-bash-3.2$ standard in must be a tty
Please help!
No, adding to sudoers file didnt solve it. there was issue with JVM where JDK was not able to initialize because of size I gave as arguments were not available, reduced and it worked.
Related
I tried few ways to safe restart either in CLI using the command "java -jar jenkins-cli.jar -s http://localhost:8080/ -webSocket safe-restart" which says - "ERROR: Unexpected exception occurred while performing safe-restart command.
hudson.lifecycle.RestartNotSupportedException: Default Windows lifecycle does not support restart."
Tried http://localhost:8080/safeRestart - Jenkins cannot restart itself as currently configured.
Can anyone solve this issue of mine. I'm using generic jenkins via jenkins.war file
For a few days I am trying to set Jenkins on Tomcat7 without any result... I read many tutorials and I could not find any help...
I set a virtual system on VirtualBox -> Ubuntu 12.04.04
Using apt-get I installed tomcat7, and then Jenkins.
While using them separately by usingcommad sudo service tomcat7 start or sudo service jenkins start both services starts and are visable on my localhost.
However, when I copied jenkins.war to /var/lib/tomcat7/webapps I cannot run it via tomcat.
I have set JENKINS_HOME as /var/lib/jenkins.
In the folder /usr/share/tomcat7 i run these commands: sudo mkdir .jenkins | sudo chown tomcat7:nogroup .jenkins
And from localhost:8080/manager jenkins is viable:
When I try localhost:8080/jenkins as tutorials says I get en error message:
I really have no idea what am I doing wrong...
What else may I try to make it work?
I had the same issue. Please check Java compatibility version with the "Jenkins.war" file. I used Java 8 for Jenkins version 2.107.1.
I would suggest to shutdown restart the tomcat server. As it should be able to read the .war file. Hence, you will go through additional setup.
Check the version of your jenkins.war file
Check the compatibe java version for hat jenkins version in web
Download that version of java and define system environment variables path for JAVA_HOME
Open "Monitor tomcat" in that JAVA define the path of jvm.dll
example C:\Program Files\Java\jdk-11.0.16\bin\server\jvm.dll
This picture shows how to run in windows:
Please check your JRE path, as I face a similar issue where JRE_HOME was incorrectly set
JRE_HOME=/usr/jdk/jdk1.6.0_21,
It started working when I correct it to latest JRE version
JRE_HOME=/usr/jdk/jdk1.7.0_09/jre.
I have a jenkins instance running. To create this instance on a Fedora 23 machine, I installed jenkins (via dnf) and started it (via systemd). It is running and I can see it in my browser at http://localhost:8080.
I have been trying to follow the directions in https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI.
I download http://localhost:8080/jnlpJars/jenkins-cli.jar to my computer.
Then I try to run the program java -jar jenkins-cli.jar http://127.0.0.1 -s help and I get no main manifest attribute, in jenkins-cli.jar
When I check jenkins-cli.jar, sure enough there is no Main-Class entry in the manifest file.
What is the proper way to invoke the jenkins cli?
Addendum
https://wiki.jenkins-ci.org/display/JENKINS/Starting+and+Accessing+Jenkins has a separate procedure for using the jenkins cli, but it does not explain where to obtain jenkins.jar.
I have worked out a kludgy solution. I hope someone has a better idea.
On my instance I run
curl http://www.java2s.com/Code/JarDownload/localizer/localizer-1.9.jar.zip > localizaer-1.9.jar.zip
unzip localizaer-1.9.jar.zip
curl http://central.maven.org/maven2/commons-codec/commons-codec/1.9/commons-codec-1.9.jar > commons-code-1.9.jar
java -classpath /usr/share/jenkins/webroot/WEB-INF/jenkins-cli.jar:/usr/share/jenkins/webroot/WEB-INF/remoting.jar:/usr/share/jenkins/webroot/WEB-INF/slave.jar:/usr/share/jenkins/webroot/WEB-INF/classes:localizer-1.9.jar:commons-code-1.9.jar:localizer-1.9.jar hudson.cli.CLI -s http://localhost:8080 help
I don't like it because it is super-kludgy, but it seems to work.
I've got a jenkins CI installed from a debian package (1.424.6 version, Debian/Ubuntu distribution, running on ubuntu 12.04). I read on the web that jenkins provides an automatic upgrade button, just like in . But I don't have such thing on my jenkins. I tried to find answers on google and in jenkins config, but failed. Maybe it's impossible for debian/ubuntu installed package?
It's a permissions problem, If you trust in your Jenkins security configuration just run:
$ chown -R jenkins /usr/share/jenkins
Then restart jenkins and the upgrade button should be shown, and you can upgrade to last version, otherwise you have to use debian package system whose Jenkins version is not the latest.
as it states in the https://wiki.jenkins-ci.org/display/JENKINS/Automated+Upgrade "Using the Upgrade-Button from within Jenkins (available since 1.318) will not work if Jenkins was installed from a Debian package (results in permission denied errors when trying to download the new WAR file)!"
so even if you find the button it will fail.
but it also says that
aptitude update && aptitude install jenkins
will update the jenkins to the newest version, give it a try :)
Change the ownership (to jenkins UID and GID) of the directory where the jenkins.war resides and the WAR file itself. For example, the following works for RHEL:
chown jenkins:jenkins /usr/lib/jenkins
chown jenkins:jenkins /usr/lib/jenkins/jenkins.war
https://wiki.jenkins-ci.org/display/JENKINS/Automated+Upgrade
If you've installed via the OS X installer, the 'jenkins' running the
process does not own the .war file. To get auto-upgrade working, just
fix the permissions so the jenkins user can write the WAR (in
/Applications/Jenkins).
run the command to find the location of jenkins.war
ps -aux | grep jenkins
output like this:
jenkins 27765 172 11.0 3528188 432288 ? Ssl 12:23 4:16 /etc/alternatives/java -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=8009 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20
location of jenkins.war is:
/usr/lib/jenkins/jenkins.war
run command to fix /usr/lib/jenkins/jenkins.war permissions. for example:
chmod 777 /usr/lib/jenkins/jenkins.war
then refresh manage page. and you will see the button.
In my case, I had installed jenkins with snap. I brought everything down with docker-compose. Then I copied the downloaded jenkins.war to the snap directory. Next, brought things up with docker-compose, then latest version appeared in the jenkins ui.
I'm running play2 on a 512M vps.
It can create a new app:
play new test
But can't start that test project:
cd test
play
It reports such an error:
[freewind#289144 test]$ play
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
[freewind#289144 test]$
After some research, I found play2 will invoke play-2.0/framework/build, and build has following settings:
I tried to modify the play-2.0/play shell, from:
java ${DEBUG_PARAM} -Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled
-XX:MaxPermSize=384M -Dfile.encoding=UTF8 -Dplay.version="${PLAY_VERSION}"
-Dsbt.ivy.home=`dirname $0`/../repository -Dplay.home=`dirname $0`
-Dsbt.boot.properties=`dirname $0`/sbt/sbt.boot.properties
-jar `dirname $0`/sbt/sbt-launch.jar "$#"
We can see that the Xms is 512M, the vps hasn't enough memory for it.
So I change it to:
java ${DEBUG_PARAM} -Xms112M -Xmx300M -Xss1M
-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=84M -Dfile.encoding=UTF8
...
This time, the error message is changed:
Error occurred during initialization of VM
Cannot create VM thread. Out of system resources.
What should I do?
Assuming you're running the Sun Hotspot VM, run it like this:
_JAVA_OPTIONS="-Xmx384m" play <your commands>
And you'll get what you need. When the VM launches, it includes the contents of the _JAVA_OPTIONS environment variable along with any other command-line Java options you specify. You'll know it was picked up because you'll see the following message on your console:
Picked up _JAVA_OPTIONS: -Xmx384m
The shell command above defines the variable only for execution of the rest of the shell command. If you wanted to make it more durable, you could say something like
export _JAVA_OPTIONS="-Xmx384m"
and put that in .bash_profile, or .profile, etc.
The _JAVA_OPTIONS environment variable is poorly documented, and I'm not sure how widely it is supported, but I'm pretty sure it works on Linux, BSD* (like Mac OS), and...I don't know what else.
I faced the same issue but I found the reason and the solution.
It is a java parameter in play. I do a simple check:
java -Xms512M -Xmx1024M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256M -version
This does not work, but
java -Xms512M -Xmx1024M -Xss1M -XX:+CMSClassUnloadingEnabled
does work! and
java -Xms512M -Xmx512M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256M
works too.
You have to modify the build.bat as I did: on maximum mem size or change the maximum permanent size.
I build and develop locally. I then run "play dist" to create a distribution which contains a start script. I deploy to my 512MB VPS using Fabric and do not have any memory issues.
Another way is to use the following command (it works when you dont use play dist but have the framework installed on the server aswell, maybe it works with the standalone package too but I have not tested it):
play "start 6000" -Xms64m -Xmx128m -server
the "start 6000" will start the server listening on port 6000.
play stage && target/start -Xmx384m