I installed the latest Jenkins on CentOS 7 following the instructions here, which includes installing Java OpenJDK 11. https://www.jenkins.io/doc/book/installing/linux/#red-hat-centos
This was successful and I was able to run Jenkins and set up a single project. A month later I saw that an update was available for Jenkins, so I went through the process of installing the latest. Possibly I did something wrong here as I simply ran the command to install Jenkins again rather than update??? At any rate, it seemed successful, but then wouldn't start. In short, it doesn't seem to recognize Java anymore. All the answers I see on this appear to be out of date, for example, to edit /etc/init.d/jenkins and add java path. How do I verify/fix the Java path for the latest version of Jenkins on CentOS 7?
**sudo systemctl start jenkins**
Job for jenkins.service failed because the control process exited with error code. See "systemctl status jenkins.service" and "journalctl -xe" for details.
**sudo systemctl status jenkins**
● jenkins.service - Jenkins Continuous Integration Server
Loaded: loaded (/usr/lib/systemd/system/jenkins.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Thu 2022-09-01 15:25:36 PDT; 5min ago
Main PID: 4512 (code=exited, status=1/FAILURE)
systemd[1]: jenkins.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Jenkins Continuous Integration Server.
systemd[1]: Unit jenkins.service entered failed state.
systemd[1]: jenkins.service failed.
systemd[1]: jenkins.service holdoff time over, scheduling restart.
systemd[1]: Stopped Jenkins Continuous Integration Server.
systemd[1]: start request repeated too quickly for jenkins.service
systemd[1]: Failed to start Jenkins Continuous Integration Server.
systemd[1]: Unit jenkins.service entered failed state.
systemd[1]: jenkins.service failed.
**sudo journalctl -xe**
-- Unit jenkins.service has begun starting up.
systemd[1]: jenkins.service: main process exited, code=exited, status=1/FAILURE
jenkins[7170]: jenkins: failed to find a valid Java installation
systemd[1]: Failed to start Jenkins Continuous Integration Server.
-- Subject: Unit jenkins.service has failed
Ends up the issue had nothing to do with the Jenkins upgrade. Somehow the symlink to Java had gotten messed up. I fixed that and Jenkins started up fine.
Related
All,
I am starting the Jenkins agent and STAF process via Crontab at my Ubuntu 14.04. When I executing opentest_cli through Jenkins job that should connect to the STAF process it says that the STAF process not alive although I see the STAF process at "ps -ef". Any idea why?
Thanks to all for helping
I was able to install and run jenkins on my linux subsystem in Windows 10.
It listens on 8082.
But unfortunately, for an unknown reason, it hangs up infinitely after a few minutes (or to be precise after a I've made a change in a job config and execute a build).
Then, I checked in the terminal:
root#jup1t3r /h/navds# service jenkins status
Correct java version found
2 instances of jenkins are running at the moment
but the pidfile /var/run/jenkins/jenkins.pid is missing
root#jup1t3r /h/navds# service jenkins stop
Correct java version found
* Stopping Jenkins Automation Server jenkins
...done.
root#jup1t3r /h/navds# service jenkins status
Correct java version found
2 instances of jenkins are running at the moment
but the pidfile /var/run/jenkins/jenkins.pid is missing
So there is no way to stop Jenkins. How can I restart it ?
I have a set of Jenkins slaves that were connected via SSH. They have all been working fine for several months. This morning, I found that all slaves were disconnected, and all had the same error when I tried to launch the agent:
01/05/18 16:27:13] [SSH] Starting slave process: cd "/home/ubuntu/jenkins_slave" && java -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Slave JVM has not reported exit code. Is it still running?
[01/05/18 16:27:20] Launch failed - cleaning up connection
[01/05/18 16:27:20] [SSH] Connection closed.
ERROR: Connection terminated
java.io.EOFException
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2638)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3113)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:853)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:349)
at hudson.remoting.ObjectInputStreamEx.<init>(ObjectInputStreamEx.java:48)
at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:59)
Caused: java.io.IOException: Unexpected termination of the channel
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:73)
One common issue I found was a mismatch between Jenkins and Java versions, but I believe mine are compatible (Jenkins server says 2.46.3 and the slaves all have Java 1.7).
Regarding "Is it still running?", I don't see a Jenkins slave process running:
ps aux | grep java
returns nothing.
I have been unable to locate any Jenkins logs on the slave side. All the logs I've found on the master side only reiterate the error pasted above.
# systemctl status jenkins
jenkins.service - LSB: Jenkins continuous build server
Loaded: loaded (/etc/rc.d/init.d/jenkins)
Active: active (exited) since Tue 2016-11-15 17:12:33 JST; 3min 58s ago
I am upgrading jenkins from 1.6 to 2.x but after replacing war file I can not start jenkins that can be seen above.
I would recommend to download the 1.6 and run it to validate all remain the same and still workable. Probably you have some plugins that not supported (or should be upgraded to be supported) in versions 2+.
While trying to improve performance of my Gradle Android builds, I stumbled across the Gradle Daemon, and have been using it with great success for local builds.
However, when running under Jenkins on Ubuntu 14.04, builds are intermittently failing with:
Starting process 'Gradle Test Executor 2'. Working directory: /tmp/myproject/android/example Command: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Djava.security.manager=worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp /data/var/lib/jenkins/.gradle/caches/2.14.1/workerMain/gradle-worker.jar worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 2'
Successfully started process 'Gradle Test Executor 2'
Daemon vm is shutting down... The daemon has exited normally or was terminated in response to a user interrupt.
Starting process 'Gradle Test Executor 3'. Working directory: /tmp/myproject/android/example Command: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Djava.security.manager=worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp /[...]/.gradle/caches/2.14.1/workerMain/gradle-worker.jar worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 3'
----- End of the daemon log -----
FAILURE: Build failed with an exception.
* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.
Error: Failed to run test (./gradlew --console=plain --info test -p myproject).
FAILURE: Build failed with an exception.
Multiple builds may be running in parallel. If I run a build manually when no other builds are running, I haven't been able to reproduce it. Someone else had this problem, but the recommended solution was just to disable the Gradle Daemon, which I don't want to do. I would think that a large, concurrent build environment would be exactly what Gradle Daemon was intended to optimize.
Or, if I can't make the Gradle Daemon work reliably under Jenkins, why not? Thanks!
The Gradle Daemon is enabled by default since version 3.0. However, the official documentation until 4.2.1 stated that you shouldn't use the daemon in continuous integration servers.
It is recommended that the Daemon is used in all developer environments. It is recommend to disable the Daemon for Continuous Integration and build server environments.
The Daemon enables faster builds, which is particularly important when a human is sitting in front of the build. For CI builds, stability and predictability is of utmost importance. Using a fresh runtime (i.e. process) for each build is more reliable as the runtime is completely isolated from previous builds.
This recommendations has changed since then, see Disabling the Daemon
Since Gradle 3.0, we enable Daemon by default and recommend using it for both developers' machines and Continuous Integration servers. However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is completely isolated from any previous builds.