I installed jenkins on Centos 7 using the following:
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import http://pkg.jenkins.io/redhat-stable/jenkins.io.key
yum install jenkins
as described on the official documentation
However when I run:
service start jenkins
I get the following error message:
Starting jenkins (via systemctl): Job for jenkins.service failed because the control process exited with error code. See "systemctl status jenkins.service" and "journalctl -xe" for details.
[FAILED]
Running systemctl status jenkins.service gives me this:
● jenkins.service - LSB: Jenkins Continuous Integration Server
Loaded: loaded (/etc/rc.d/init.d/jenkins)
Active: failed (Result: exit-code) since Wed 2016-09-21 16:45:28 BST; 3min 59s ago
Docs: man:systemd-sysv-generator(8)
Process: 2818 ExecStart=/etc/rc.d/init.d/jenkins start (code=exited, status=1/FAILURE)
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: at com.sun.akuma.JavaVMArguments.of(JavaVMArguments...04)
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: at com.sun.akuma.JavaVMArguments.current(JavaVMArgu...92)
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: at com.sun.akuma.Daemon.daemonize(Daemon.java:106)
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: at com.sun.akuma.Daemon.all(Daemon.java:88)
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: ... 6 more
Sep 21 16:45:28 webstack.local.caplib systemd[1]: jenkins.service: control process exited, code=exited s...s=1
Sep 21 16:45:28 webstack.local.caplib systemd[1]: Failed to start LSB: Jenkins Continuous Integration Server.
Sep 21 16:45:28 webstack.local.caplib systemd[1]: Unit jenkins.service entered failed state.
Sep 21 16:45:28 webstack.local.caplib systemd[1]: jenkins.service failed.
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: [FAILED]
Hint: Some lines were ellipsized, use -l to show in full.
and running journalctl -xe gives me this:
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: at com.sun.akuma.JavaVMArguments.of(JavaVMArguments.java:
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: at com.sun.akuma.JavaVMArguments.current(JavaVMArguments.
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: at com.sun.akuma.Daemon.daemonize(Daemon.java:106)
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: at com.sun.akuma.Daemon.all(Daemon.java:88)
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: ... 6 more
Sep 21 16:45:28 webstack.local.caplib runuser[2819]: pam_unix(runuser:session): session closed for user jenkin
Sep 21 16:45:28 webstack.local.caplib systemd[1]: jenkins.service: control process exited, code=exited status=
Sep 21 16:45:28 webstack.local.caplib systemd[1]: Failed to start LSB: Jenkins Continuous Integration Server.
-- Subject: Unit jenkins.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit jenkins.service has failed.
--
-- The result is failed.
Sep 21 16:45:28 webstack.local.caplib systemd[1]: Unit jenkins.service entered failed state.
Sep 21 16:45:28 webstack.local.caplib systemd[1]: jenkins.service failed.
Sep 21 16:45:28 webstack.local.caplib jenkins[2818]: [FAILED]
Sep 21 16:45:28 webstack.local.caplib polkitd[1392]: Unregistered Authentication Agent for unix-process:2813:8
Sep 21 16:45:28 webstack.local.caplib dhclient[1390]: DHCPREQUEST on eno16777984 to 192.168.15.254 port 67 (xi
Sep 21 16:45:28 webstack.local.caplib dhclient[1390]: DHCPACK from 192.168.15.254 (xid=0x2ab6e6bc)
Sep 21 16:45:30 webstack.local.caplib dhclient[1390]: bound to 192.168.15.120 -- renewal in 865 seconds.
Sep 21 16:45:36 webstack.local.caplib systemd[1]: Starting Cleanup of Temporary Directories...
-- Subject: Unit systemd-tmpfiles-clean.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-tmpfiles-clean.service has begun starting up.
Sep 21 16:45:36 webstack.local.caplib systemd[1]: Started Cleanup of Temporary Directories.
-- Subject: Unit systemd-tmpfiles-clean.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-tmpfiles-clean.service has finished starting up.
--
-- The start-up result is done.
Both of which is really unhelpful. How do I fix this issue?
Similar problem on Ubuntu 16.04.
Setting up jenkins (2.72) ...
Job for jenkins.service failed because the control process exited with error code. See "systemctl status jenkins.service" and "journalctl -xe" for details.
invoke-rc.d: initscript jenkins, action "start" failed.
● jenkins.service - LSB: Start Jenkins at boot time
Loaded: loaded (/etc/init.d/jenkins; bad; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2017-08-01 05:39:06 UTC; 7ms ago
Docs: man:systemd-sysv-generator(8)
Process: 3700 ExecStart=/etc/init.d/jenkins start (code=exited, status=1/FAILURE)
Aug 01 05:39:06 ip-0 systemd[1]: Starting LSB: Start Jenkins ....
Aug 01 05:39:06 ip-0 jenkins[3700]: ERROR: No Java executable ...
Aug 01 05:39:06 ip-0 jenkins[3700]: If you actually have java ...
Aug 01 05:39:06 ip-0 systemd[1]: jenkins.service: Control pro...1
Aug 01 05:39:06 ip-0 systemd[1]: Failed to start LSB: Start J....
Aug 01 05:39:06 ip-0 systemd[1]: jenkins.service: Unit entere....
Aug 01 05:39:06 ip-0 systemd[1]: jenkins.service: Failed with....
To fix the issue manually install Java Runtime Environment:
JDK version 9:
sudo apt install openjdk-9-jre
JDK version 8:
sudo apt install openjdk-8-jre
Open Jenkins configuration file:
sudo vi /etc/init.d/jenkins
Finally, append path to the new java executable (line 16):
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/lib/jvm/java-8-openjdk-amd64/bin/
ERROR: Linux / Centos:
Job for jenkins.service failed because the control process exited with error code. See "systemctl status jenkins.service" and "journalctl -xe" for details.
Solution:
Edit the Jenkins init file by doing
sudo vi /etc/init.d/jenkins
Add your own Java path, for example:
/opt/oracle/product/java/jdk1.8.0_45/bin/java
Restart the service:
sudo service jenkins start
sudo service jenkins status
sudo service jenkins stop
I had a similar problem on Ubuntu 16.04. Thanks to #Guna I figured out that I had to manually install Java (sudo apt install openjdk-8-jre).
I had a similar issue on CentOS 7 while a correct version of Java was installed and java -version gave a nice result.
Collecting multiple answers from different SO threads I did the following:
Make sure Java is installed (and version is compatible with Jenkins)
There're some tricks if saying about CentOS, this is mentioned in official Jenkins tutorial here
If Java is installed and available, when running java -v output should look like this:
~>$java -version
openjdk version "1.8.0_161"
OpenJDK Runtime Environment (build 1.8.0_161-b14)
OpenJDK 64-Bit Server VM (build 25.161-b14, mixed mode)
Add a path to Java to your /etc/rc.d/init.d/jenkins
~>$ sudo vim /etc/rc.d/init.d/jenkins
candidates="
/etc/alternatives/java
/usr/lib/jvm/java-1.8.0/bin/java
/usr/lib/jvm/jre-1.8.0/bin/java
/usr/lib/jvm/java-1.7.0/bin/java
/usr/lib/jvm/jre-1.7.0/bin/java
/usr/bin/java
/usr/java/jdk1.8.0_162/bin/java ##add your java path here
"
How to get your 'real' path to java distributive which is called when you type smth like java -v
Follow this SO thread
If steps above didn't help, try to make sure all permission issues are resolved:
If Jenkins fails to run Java, it could be jenkins user doesn't have permissions to run it, then change jenkins to root in config (described here)
Try to play with chmod setting 755 permissions to java installation folder
And finally what helped me in result
When I did run journalctl -xe as was suggested when I've tried to sudo service jenkins start, I got similar Java stacktrace:
Starting CloudBees Jenkins Enterprise Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at Main._main(Main.java:140)
at Main.main(Main.java:98)
Caused by: java.lang.UnsatisfiedLinkError: /tmp/jna--1712433994/jna7387046629130767794.tmp: /tmp/jna--1712433994/jna7387046629130767794.tmp: failed to map segment from shared object: Operation not permitted
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:761)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:736)
at com.sun.jna.Native.<clinit>(Native.java:131)
at com.sun.akuma.CLibrary.<clinit>(CLibrary.java:89)
at com.sun.akuma.JavaVMArguments.resolvePID(JavaVMArguments.java:128)
at com.sun.akuma.JavaVMArguments.ofLinux(JavaVMArguments.java:116)
at com.sun.akuma.JavaVMArguments.of(JavaVMArguments.java:104)
at com.sun.akuma.JavaVMArguments.current(JavaVMArguments.java:92)
at com.sun.akuma.Daemon.daemonize(Daemon.java:106)
at com.sun.akuma.Daemon.all(Daemon.java:88)
... 6 more
The problem is that Jenkins tries to launch JNA library from /tmp dir which is marked as noexec by default, so we it could be fixed by creating a temporary directory in a /jenkins path so it could be executed.
The full way to do this is described here by CloudBees support (thanks a lot for them)
I hope something from this list will help (as well I mostly leave it for me in the future when I'll have to install Jenkins for CentOs again :)
Before you install Jenkins you should install JDK:
apt install openjdk-8-jre
After this install Jenkins:
apt-get install jenkins
And check Jenkins status (should be 'active'):
systemctl status jenkins.service
The easiest possible fix for this issue if it is a AWS linux instance
sudo yum install java-1.8.0 -y
sudo yum remove java-1.7.0-openjdk
Still fighting the same error on both ubuntu, ubuntu derivatives and opensuse. This is a great way to bypass and move forward until you can fix the actual issue.
Just use the docker image for jenkins from dockerhub.
docker pull jenkins/jenkins
docker run -itd -p 8080:8080 --name jenkins_container jenkins
Use the browser to navigate to:
localhost:8080 or my_pc:8080
To get at the token at the path given on the login screen:
docker exec -it jenkins_container /bin/bash
Then navigate to the token file and copy/paste the code into the login screen. You can use the edit/copy/paste menus in the kde/gnome/lxde/xfce terminals to copy the terminal text, then paste it with ctrl-v
War File
Or use the jenkins.war file. For development purposes you can run jenkins as your user (or as jenkins) from the command line or create a short script in /usr/local or /opt to start it.
Download the jenkins.war from the jenkins download page:
https://jenkins.io/download/
Then put it somewhere safe, ~/jenkins would be a good place.
mkdir ~/jenkins; cp ~/Downloads/jenkins.war ~/jenkins
Then run:
nohup java -jar ~/jenkins/jenkins.war > ~/jenkins/jenkins.log 2>&1
To get the initial admin password token, copy the text output of:
cat /home/my_home_dir/.jenkins/secrets/initialAdminPassword
and paste that into the box with ctrl-v as your initial admin password.
Hope this is detailed enough to get you on your way...
I had the same issue, and when I checked if Java is installed I realised it's not, so installing Java solved the problem for me.
Check for java:
java -version
If Java is installed in the system, the command will return the java version otherwise it will show a message like this.
The program 'java' can be found in the following packages:
* default-jre
* gcj-5-jre-headless
* openjdk-8-jre-headless
* gcj-4.8-jre-headless
* gcj-4.9-jre-headless
* openjdk-9-jre-headless
To install java use the following command.
sudo apt-get install default-jre
[100 %]Solved. I had the same problem today. I checked my server space
df-h
I saw that server is out of space so i check which directory has most size by
sudo du -ch / | sort -h
I saw 12.2G /var/lib/jenkins so i entered this folder and cleared all the logs by
cd /var/libs/jenkins
rm *
and restart the jenkins it will work normal
sudo systemctl restart jenkins.service
I was trying to install it in kubuntu 18.04, and i was already sure that i had java installed,
I confirmed by trying
java -version
I got the output like that
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
Since I already know that my java PATH variables are defined in /etc/environment file, I added that file to the top of /etc/init.d/jenkins file
source /etc/environment
you can even remove the PATH from /etc/init.d/jenkins file, since it's already defined in /etc/environment
after that, i restarted my jenkins server,and it seemed to start working fine from localhost:8080
In my case, the port 8080 was taken by some other service (Apache Airflow).
So I edit the HTTP port in this file:
sudo vi /etc/default/jenkins
And then started the service and it worked:
sudo service jenkins start
I was on Ubuntu 18.04 and installed openjdk-8
Jenkins, by default, makes use of port 8080, please make sure its not occupied by other applications.
To check if a port is available, try running
curl localhost:8080
If port is available, this should result in an error like:
curl: (7) Failed to connect to localhost port 8080: Connection refused
If the port is occupied, Jenkins port can be changed by:
sudo systemctl edit --full jenkins.service
and setting:
Environment="JENKINS_PORT=<ANY_AVAILABLE_PORT>"
Then run:
sudo systemctl restart jenkins.service
For ubuntu 16.04, there is firewall issue. You need to open 8080 port using following command:
sudo ufw allow 8080
Detailed steps are given here: https://www.digitalocean.com/community/tutorials/how-to-install-jenkins-on-ubuntu-16-04
Installing Java fixed this issue for me!
please try to install it like this:
sudo apt install openjdk-11-jdk
Amazon linux
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat/jenkins.io.key
amazon-linux-extras install epel
amazon-linux-extras install java-openjdk11
yum install jenkins
systemctl start jenkins
---just follow steps--
Adding on to what has been already answered by Guna Sekaran. Jenkins need the user jenkins to be present in order to run the jenkins as a service.
To add user fire 'useradd jenkins' as root
and fire 'passwd jenkins' as root before starting Jenkins as a service.
~>$ sudo vim /etc/rc.d/init.d/jenkins
candidates="
/etc/alternatives/java
/usr/lib/jvm/java-1.8.0/bin/java
/usr/lib/jvm/jre-1.8.0/bin/java
/usr/lib/jvm/java-1.7.0/bin/java
/usr/lib/jvm/jre-1.7.0/bin/java
/usr/bin/java
/usr/java/jdk1.8.0_162/bin/java ##add your java path
"
You just need to install Java.
It did work after installing Java version 8,
using this command : sudo apt install openjdk-8-jre-headless
Looks like java version conflicts.
Please refer https://medium.com/lucian-daniliuc/upgrading-jenkins-on-ubuntu-14-04-lts-df3e1209f98c
I faced same issue while setting up jenkins, the problem is that java is not installed and hence not available in path.
The simplest way is to use scp here to copy jdk binaries to aws ec2 box, script won't work if you make one as they keep on updating download urls(Orale, i mean):
scp -i C:/Users/key-pair.pem jdk-8u191-linux-x64.tar.gz ec2-
user#54.183.220.7:~/
$cd /opt
$sudo cp /home/ec2-user/jdk* .
$sudo chmod +x jdk*
$sudo tar xzf jdk-8u191-linux-x64.tar.gz
$sudo tar xzf jdk-8u191-linux-x64.tar.gz
$cd jdk1.8.0_191/
$sudo alternatives --install /usr/bin/java java /opt/jdk1.8.0_191/bin/java 2
$sudo alternatives --config java
Here I download tar.gz file in loal windows and transferred over scp to AWS ec2-user, default dir. Hope it helps.
I had below error:
Job for jenkins.service failed because the control process exited with error code. See "systemctl status jenkins.service" and "journalctl -xe" for details.
Solution was to revert the NAME to jenkins in the below file (Earlier I have changed it to 'NAME=ubuntu'):
sudo vi /etc/default/jenkins
NAME=jenkins
Now restart passed:
sudo service jenkins restart
sudo systemctl restart jenkins.service
Hope that helps.
In my case, the issue was of unsupported java version
Check the file /etc/init.d/jenkins to find out which java versions are supported.
To find which java versions are supported, run
grep -m 1 "JAVA_ALLOWED_VERSIONS" /etc/init.d/jenkins
The output will be like this(your's might be different)
JAVA_ALLOWED_VERSIONS=( "1.8" "11" )
In my case version 1.8 and 11 are supported. I will be going with version 11.
Install the supported version of jre using command
For ubuntu/debian
sudo apt install openjdk-11-jre
For centOS use
sudo yum install java-11-openjdk-devel
Find the path to newly installed jre
For ubuntu/debian path is
/usr/lib/jvm/java-11-openjdk-amd64/bin/java
You can find the path on centOS under /usr/lib/jvm/
Modify the file /etc/init.d/jenkins
At line number 28, replace the JAVA=`type -p java` with JAVA='/usr/lib/jvm/java-11-openjdk-amd64/bin/java'
Now run command to reload the systemctl daemon
sudo systemctl daemon-reload
Start the jenkins service
sudo systemctl start jenkins
[root~]# 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.
[root~]#
[root~]# systemctl status jenkins.service
● jenkins.service - LSB: Jenkins Automation Server
Loaded: loaded (/etc/rc.d/init.d/jenkins; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2021-08-26 03:31:13 UTC; 12s ago
Docs: man:systemd-sysv-generator(8)
Process: 3465 ExecStart=/etc/rc.d/init.d/jenkins start (code=exited, status=1/FAILURE)
Aug 26 03:31:13 ip-172-31-11-0.ap-south-1.compute.internal systemd[1]: Starting LSB: Jenkins Automation Server...
Aug 26 03:31:13 ip-172-31-11-0.ap-south-1.compute.internal jenkins[3465]: Starting Jenkins File "/usr/bin/java" is not executable.
Aug 26 03:31:13 ip-172-31-11-0.ap-south-1.compute.internal jenkins[3465]: [FAILED]
Aug 26 03:31:13 ip-172-31-11-0.ap-south-1.compute.internal systemd[1]: jenkins.service: control process exited, code=exited status=1
Aug 26 03:31:13 ip-172-31-11-0.ap-south-1.compute.internal systemd[1]: Failed to start LSB: Jenkins Automation Server.
Aug 26 03:31:13 ip-172-31-11-0.ap-south-1.compute.internal systemd[1]: Unit jenkins.service entered failed state.
Aug 26 03:31:13 ip-172-31-11-0.ap-south-1.compute.internal systemd[1]: jenkins.service failed.
I had this problem. and the problem was that I haven't installed java. This is for Amazon Linux. To install Java on Amazon Linux use : sudo yum install java.
same error in my case,I tried all the above solutions ,none of them work because java is not the problem here.Please follow this steps for success.
before hitting sudo yum install jenkins java-1.8.0-openjdk-devel -y, you need to proceed this below step
step1: sudo amazon-linux-extras install epel -y
step2:sudo vi vim /etc/yum.repos.d/epelfordaemonize.repo (it will open vim)
step3:Enter this command after step2(vim is open)
[daemonize]
baseurl=https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/
gpgcheck=no
enabled=yes
step4: For saving those command, type :wq and hit enter again write :wq and hit enter,it will save and return back.
step5: Now,sudo yum install jenkins java-1.8.0-openjdk-devel -y,it will work
Install the certificates-
sudo apt install ca-certificates
then,
Try Updating & Upgrading the packages-
sudo apt upgrade
sudo apt update
Then follow the link to install the Jenkins :)
https://www.digitalocean.com/community/tutorials/how-to-install-jenkins-on-ubuntu-18-04
I use docker for jenkins.
You should be use https://hub.docker.com/r/jenkins/jenkins instead https://hub.docker.com/_/jenkins
First, install JDK version 8:
sudo apt install openjdk-8-jre
Second, Choose version 8 as your default java environment by simply running
sudo update-alternatives --config java
Finally, Run
sudo systemctl start jenkins
Now, open port 8080 to login to Jenkins!
To stop it run:
sudo systemctl stop jenkins
In my case, my first error where I got the error message above was due to /usr/share/jenkins/jenkins.war missing. I had manually set it as a symlink, and running apt-get upgrade removed the symlink.
Fix was to download the latest jenkins.war from jenkins.io (or restoring the symlink to point to the latest version).
After this I still got the same error, and by starting Jenkins manually:
java -jar jenkins.war
I got the following error message
SEVERE: Running with Java class version 52, which is older than the Minimum required version 55. See https://jenkins.io/redirect/java-support/
Jenkins requires Java versions [17, 11] but you are running with Java 1.8
Upgrading openjdk to version 11 (or 17) solved the problem:
apt-get install openjdk-11-jre
vi /etc/init.d/jenkins
add:
/usr/lib/jvm/java/jre/bin/java
In my case I were starting jenkins service from root instead of jenkins user
i did
sed -i 's/JENKINS_USER="jenkins"/JENKINS_USER="root"/g /etc/sysconfig/jenkins
then
service jenkins restart
all work well
Related
Background
I have a Jenkins server on Ubuntu 18.04 running Java version 11, checked by visiting /manage/systemInfo
java.specification.version 11
I have implemented docker build slaves based on Ubuntu 22.04 where I have specified that the java version should be 11:
# install java for Jenkins
RUN apt-get install -qy openjdk-11-jdk
I was wondering that all the build nodes stood as offline, and reading the log saw this:
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: hudson/remoting/Launcher has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
This question references List of Java class file format major version numbers? the Class versions:
52 is java 8
55 is java 11
and sure enough, a little further back in the log:
[11/14/22 18:35:38] [SSH] Checking java version of java
[11/14/22 18:35:38] [SSH] java -version returned 1.8.0_312.
so I went hunting for the culprit:
Attempts to find the culprit
sudo docker container exec 20e1bfe2b182 ls -l /usr/bin/java returned
/usr/bin/java -> /etc/alternatives/java
sudo docker container exec 20e1bfe2b182 ls -l /etc/alternatives/java returned
/etc/alternatives/java -> /usr/lib/jvm/java-11-openjdk-amd64/bin/java
and even injected RUN java -version into my Dockerfile before the line installing opendjk (which indicated no java was installed...)
On the host I have run apt list --installed |grep jdk
openjdk-11-jdk/bionic-updates,bionic-security,now 11.0.17+8-1ubuntu2~18.04 amd64 [installed]
openjdk-11-jdk-headless/bionic-updates,bionic-security,now 11.0.17+8-1ubuntu2~18.04 amd64 [installed]
openjdk-11-jre/bionic-updates,bionic-security,now 11.0.17+8-1ubuntu2~18.04 amd64 [installed]
openjdk-11-jre-headless/bionic-updates,bionic-security,now 11.0.17+8-1ubuntu2~18.04 amd64 [installed,automatic]
... the same command on the docker image gave similar results...
find -name java* 2>/dev/null run from / did not give anything useful either
which java output
HOST:
$ which java
/usr/bin/java
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Nov 24 2018 /usr/bin/java -> /etc/alternatives/java
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 43 Jan 25 2022 /etc/alternatives/java -> /usr/lib/jvm/java-11-openjdk-amd64/bin/java
docker
$ sudo docker compose run man which java
/usr/bin/java
$ sudo docker compose run man ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Nov 14 20:28 /usr/bin/java -> /etc/alternatives/java
$ sudo docker compose run man ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 43 Nov 14 20:28 /etc/alternatives/java -> /usr/lib/jvm/java-11-openjdk-amd64/bin/java
echo $PATH output
HOST
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
docker
$ sudo docker compose run man echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Potential workaround
Adding this to my Dockerfile seems to almost solve the issue:
RUN ln -s /usr/lib/jvm/java-11-openjdk-amd64/ /home/jenkins/jdk
RUN chown jenkins:jenkins /home/jenkins/jdk
Question
... so where does the JDK version 8 come from?
Was trying to install npm and got message "ERROR: npm is known not to run on Node.js v11.4.0"
So unsinstalled nodejs and then mosquitto got stucked.
I can not start it .
pi#raspberrypi:/etc/mosquitto $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
pi#raspberrypi:~ $ sudo systemctl start mosquitto.service
Job for mosquitto.service failed because a fatal signal was delivered to the control process.
See "systemctl status mosquitto.service" and "journalctl -xe" for details.
if I run
pi#raspberrypi:~ $ systemctl status mosquitto.service
● mosquitto.service - Mosquitto MQTT Broker
Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)
Active: failed (Result: signal) since Sun 2022-08-21 15:29:29 -03; 23s ago
Docs: man:mosquitto.conf(5)
man:mosquitto(8)
Process: 820 ExecStartPre=/bin/mkdir -m 740 -p /var/log/mosquitto (code=exited, status=0/SUCCESS)
Process: 821 ExecStartPre=/bin/chown mosquitto /var/log/mosquitto (code=exited, status=0/SUCCESS)
Process: 822 ExecStartPre=/bin/mkdir -m 740 -p /run/mosquitto (code=exited, status=0/SUCCESS)
Process: 823 ExecStartPre=/bin/chown mosquitto /run/mosquitto (code=exited, status=0/SUCCESS)
Process: 824 ExecStart=/usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf (code=killed, signal=ILL)
Main PID: 824 (code=killed, signal=ILL)
if I go to the mosquitto folder
pi#raspberrypi:/etc/mosquitto $ ls -l
total 16
drwxr-xr-x 2 root root 4096 Aug 19 14:20 ca_certificates
drwxr-xr-x 2 root root 4096 Aug 19 14:20 certs
drwxr-xr-x 2 root root 4096 Aug 19 14:20 conf.d
-rw-r--r-- 1 root root 385 Aug 20 21:31 mosquitto.conf
And this is my mosquitto.conf file
# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.gz
pid_file /run/mosquitto/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
listener 1883
allow_anonymous true
I have manually added ,listener and allow, to see if that would make any difference. But same result<
If I run, I get illegal instruction. Do not understand why...
pi#raspberrypi:~ $ sudo /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Illegal instruction
Also can not get version since I get illegal instruction....
pi#raspberrypi:/etc/mosquitto $ mosquitto -v
Illegal instruction
pi#raspberrypi:/etc/mosquitto $ mosquitto -h
Illegal instruction
pi#raspberrypi:/etc/mosquitto $ file 'which mosquitto'
which mosquitto: cannot open `which mosquitto' (No such file or directory)
pi#raspberrypi:/etc/mosquitto $ uname -a
Linux raspberrypi 4.19.75+ #1270 Tue Sep 24 18:38:54 BST 2019 armv6l GNU/Linux
pi#raspberrypi:~ $ dpkg -s mosquitto
Package: mosquitto
Status: install ok half-configured
Priority: optional
Section: net
Installed-Size: 550
Maintainer: Roger A. Light <roger#atchoo.org>
Architecture: armhf
Multi-Arch: foreign
Version: 2.0.12-0mosquitto1~buster1
Config-Version: 1.6.10-0mosquitto1~buster1
Depends: adduser (>= 3.10), lsb-base (>= 4.1+Debian3), libc6 (>= 2.28), libcjson 1 (>= 1.7.5), libmosquitto1 (>= 1.6), libssl1.1 (>= 1.1.1), libsystemd0, libwebs ockets18 (>= 4.2.1), libwrap0 (>= 7.6-4~)
Suggests: apparmor
Conffiles:
/etc/init.d/mosquitto ee3001555cef9450c46fb2148c654cd1
/etc/logrotate.d/mosquitto f74e922f3bf6b513f76d5e47fabfb322
/etc/mosquitto/ca_certificates/README c1c6ae67f2def06c6a483be09b49d4de
/etc/mosquitto/certs/README 4d8a70d4cefab07d4dabc5be1f786c1f
/etc/mosquitto/conf.d/README b4ac621550824082a735732bfb42b51d
/etc/mosquitto/mosquitto.conf 6b48f97e52925e8cad9f32f991ef100d
Description: MQTT version 3.1/3.1.1/5.0 compatible message broker
This is a message broker that supports version 5.0 and 3.1.1 of the MQTT
protocol.
.
MQTT provides a method of carrying out messaging using a publish/subscribe model. It is lightweight, both in terms of bandwidth usage and ease of implementation.
pi#raspberrypi:~ $ ls /etc/apt
apt.conf.d listchanges.conf sources.list trusted.gpg trusted.gpg.d
auth.conf.d preferences.d sources.list.d trusted.gpg~
pi#raspberrypi:~ $ ls /etc/apt/sources.list.d
raspi.list
pi#raspberrypi:~ $ cd /etc/apt/sources.list.d
pi#raspberrypi:/etc/apt/sources.list.d $ ls -l
total 4
-rw-r--r-- 1 root root 284 Aug 19 10:55 raspi.list
Inside the file I have
#deb [trusted=yes] http://archive.raspberrypi.org/debian/ buster main
deb http://mirror.ufam.edu.br/raspbian/raspbian/ buster main contrib non- free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.org/debian/ buster main
Any idea how to bring back to life mosquitto?
OK,
I have reproduced this, you installed from the mosquitto ppa which provides both mosquitto and a newer copy of libwebsocket.
The SIGILL is coming from the libwebsocket library that appears to have been built targeting ARMv7 not ARMv6 (which is what the Pi Zero [W]) is using.
I have raised this with the mosquitto maintainer, with any luck it will fixed soon and upgrading will fix the problem.
Found similar problem here https://forums.raspberrypi.com/viewtopic.php?t=334388
fixed with these commands
apt remove mosquitto libwebsockets18
apt install mosquitto libwebsockets18=4.2.1-0mosquitto1~buster1
So, I've seen answers for when Jenkins totally fails to start. It looks like I have a slightly different problem where Jenkins runs but then immediately exits.
After an EC2 instance reboot, I tried this:
λ ip-xx-xxx-xx-xx jenkinshome → sudo service jenkins start
Starting jenkins (via systemctl): [ OK ]
λ ip-xx-xxx-xx-xx jenkinshome → sudo service jenkins status
● jenkins.service - LSB: Jenkins Automation Server
Loaded: loaded (/etc/rc.d/init.d/jenkins; bad; vendor preset: disabled)
Active: active (exited) since Fri 2020-11-13 22:32:56 UTC; 3s ago
Docs: man:systemd-sysv-generator(8)
Process: 14875 ExecStop=/etc/rc.d/init.d/jenkins stop (code=exited, status=0/SUCCESS)
Process: 14897 ExecStart=/etc/rc.d/init.d/jenkins start (code=exited, status=0/SUCCESS)
Nov 13 22:32:55 xx...xx systemd[1]: Starting LSB: Jenkins Automation Server...
Nov 13 22:32:55 xx...xx runuser[14902]: pam_unix(runuser:session): session opened for user jenkins by (uid=0)
Nov 13 22:32:56 xx...xx systemd[1]: Started LSB: Jenkins Automation Server.
Nov 13 22:32:56 xx...xx jenkins[14897]: Starting Jenkins [ OK ]
Additionally, running java -jar /usr/lib/jenkins/jenkins.war just seems to install and start a new jenkins instance, rather than starting my previously running jenkins instance.
Worth noting: I'm at very little free space left on my device, and there are significant admin hurdles for cleaning disk space and for getting more space allocated, though this may be related.
Not quite sure how to proceed, but any tips are welcome. Thanks!
The answer was fairly straightforward, and dare I say obvious: I needed to reinstall jenkins. I'm on RHEL, but this could be adapted for ubuntu, etc. (see link below).
# stop the jenkins service altogether
sudo service jenkins stop
# backup jenkins_home files
sudo cp -r /var/lib/jenkins ~/.jenkins_home_backup
# remove the jenkins installation entirely
sudo yum remove jenkins # remove existing jenkins install
# add the jenkins ssh key locally
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
# reinstall jenkins
sudo yum -y install jenkins
# start jenkins!
sudo service jenkins start
More or less adapted from: https://computingforgeeks.com/how-to-install-jenkins-on-centos-rhel-8/
You may need to also reference: https://www.jenkins.io/blog/2020/07/27/repository-signing-keys-changing/
Unlock an HTTP port and provide the Firewall access by executing below two commands
firewall-cmd --permanent -add-port=<port_num>/tcp
firewall-cmd --reload
Start Jenkins by providing the user-defined port number:
java -jar jenkins.war --httpPort=<port_num>
If the issue still exists, then check the space of that directory where Jenkins running. If not enough space, then move that Jenkins to another directory where enough space exists.
Check Directory level permission and also file level permissions.
Hope it will work for your issue!
this is what worked for me -
sudo chown -R jenkins:jenkins /var/lib/jenkins
sudo chown -R jenkins:jenkins /var/cache/jenkins
sudo chown -R jenkins:jenkins /var/log/jenkins
sudo systemctl restart jenkins
Docker was working fine on Ubuntu box. Then, the Java version was updated for a different reason.
Now, all on a sudden docker is no longer running.
Tried different approach to recover, but it did not avail. Any pointers would help. Thanks.
$ sudo systemctl start docker
Job for docker.service failed because the control process exited with error code.
$ systemctl status docker.service
● docker.service - LSB: Create lightweight, portable, self-sufficient containers.
Loaded: loaded (/etc/init.d/docker; generated)
Drop-In: /etc/systemd/system/docker.service.d
└─10_docke_proxy.conf
Active: failed (Result: exit-code) since Thu 2020-04-23 17:06:05 EDT; 11s ago
Docs: man:systemd-sysv-generator(8)
Process: 8962 ExecStart=/etc/init.d/docker start (code=exited, status=1/FAILURE)
Main PID: 2746 (code=exited, status=0/SUCCESS)
Apr 23 17:06:05 ******** systemd[1]: Starting LSB: Create lightweight, portable, self-sufficient containers....
Apr 23 17:06:05 ******** docker[8962]: * /usr/bin/dockerd not present or not executable
Apr 23 17:06:05 ******** systemd[1]: docker.service: Control process exited, code=exited status=1
Apr 23 17:06:05 ******** systemd[1]: docker.service: Failed with result 'exit-code'.
Finally use this fixed.
wget -qO- https://get.docker.com/ | sh
This is the output
# Executing docker install script, commit: 26ff363bcf3b3f5a00498ac43694bf1c7d9ce16c
Warning: the "docker" command appears to already exist on this system.
If you already have Docker installed, this script can cause trouble, which is
why we're displaying this warning and provide the opportunity to cancel the
installation.
If you installed the current Docker package using this script and are using it
again to update Docker, you can safely ignore this message.
You may press Ctrl+C now to abort this script.
+ sleep 20
+ sh -c apt-get update -qq >/dev/null
+ sh -c DEBIAN_FRONTEND=noninteractive apt-get install -y -qq apt-transport-https ca-certificates curl >/dev/null
+ sh -c curl -fsSL "https://download.docker.com/linux/ubuntu/gpg" | apt-key add -qq - >/dev/null
Warning: apt-key output should not be parsed (stdout is not a terminal)
+ sh -c echo "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable" > /etc/apt/sources.list.d/docker.list
+ sh -c apt-get update -qq >/dev/null
W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target Packages (stable/binary-all/Packages) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target Translations (stable/i18n/Translation-en_US) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target Translations (stable/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target CNF (stable/cnf/Commands-amd64) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target CNF (stable/cnf/Commands-all) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target Packages (stable/binary-all/Packages) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target Translations (stable/i18n/Translation-en_US) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target Translations (stable/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target CNF (stable/cnf/Commands-amd64) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
W: Target CNF (stable/cnf/Commands-all) is configured multiple times in /etc/apt/sources.list:56 and /etc/apt/sources.list.d/docker.list:1
+ [ -n ]
+ sh -c apt-get install -y -qq --no-install-recommends docker-ce >/dev/null
+ sh -c docker version
Client: Docker Engine - Community
Version: 19.03.12
API version: 1.40
Go version: go1.13.10
Git commit: 48a66213fe
Built: Mon Jun 22 15:45:36 2020
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.12
API version: 1.40 (minimum version 1.12)
Go version: go1.13.10
Git commit: 48a66213fe
Built: Mon Jun 22 15:44:07 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683
If you would like to use Docker as a non-root user, you should now consider
adding your user to the "docker" group with something like:
sudo usermod -aG docker your-user
Remember that you will have to log out and back in for this to take effect!
WARNING: Adding a user to the "docker" group will grant the ability to run
containers which can be used to obtain root privileges on the
docker host.
Refer to https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface
for more information.
this worked for me:
$ sudo apt remove docker
$ sudo apt install docker docker-ce
I recommend to everyone to follow the official documentation. Which also starts with removing any old libraries then adding the GPG keys then installing the stable version of the library.
I used "Install from a package" method from Docker's official page. We have to install three deb packages. docker-ce, docker-ce-cli and containerd.io. I got this issue resolved by using all three debs released on the same date.
I fixed the issue by going back to the old jdk1.8.0_XXX the system had.
Updating to jdk-11.X.X was causing the issue in this case.
When I run docker build I get this:
Sending build context to Docker daemon 10.24kB
WARN[11935] Couldn't run auplink before unmount /var/lib/docker/aufs/mnt/21647778a50f097d4535246ec5206960dd909f4bb8b0e3d04fdd53a7402fc2de-init: exec: "auplink": executable file not found in $PATH
Step 1/2 : FROM debian:jessie
---> 86baf4e8cde9
Step 2/2 : RUN apt-get update
WARN[11935] Couldn't run auplink before unmount /var/lib/docker/aufs/mnt/21647778a50f097d4535246ec5206960dd909f4bb8b0e3d04fdd53a7402fc2de: exec: "auplink": executable file not found in $PATH
---> Running in 1fef9bef5bf7
ERRO[11934] containerd: start container error="shim error: fork/exec /usr/bin/docker-runc: exec format error" id=1fef9bef5bf77141a97669d2aa785e74f9027a849919a937f714e93fbae3916d
ERRO[11935] Create container failed with error: shim error: fork/exec /usr/bin/docker-runc: exec format error
ERRO[11934] containerd: deleting container error="fork/exec /usr/bin/docker-runc: exec format error: \"\""
WARN[11935] Couldn't run auplink before unmount /var/lib/docker/aufs/mnt/21647778a50f097d4535246ec5206960dd909f4bb8b0e3d04fdd53a7402fc2de: exec: "auplink": executable file not found in $PATH
shim error: fork/exec /usr/bin/docker-runc: exec format error
Here is the content of my Dockerfile:
FROM debian:jessie
RUN apt-get update
What is the issue? It makes no sens to me.
ll /usr/bin | grep docker
-rwxr-xr-x 1 root root 18471276 Aug 3 22:08 docker*
-rwxr-xr-x 1 root root 9938352 Aug 3 22:08 docker-containerd*
-rwxr-xr-x 1 root root 8941944 Aug 3 22:08 docker-containerd-ctr*
-rwxr-xr-x 1 root root 3824920 Aug 3 22:08 docker-containerd-shim*
-rwxr-xr-x 1 root root 40328816 Aug 3 22:08 dockerd*
-rwxr-xr-x 1 root root 0 Aug 3 22:08 docker-init*
-rwxr-xr-x 1 root root 0 Aug 3 22:08 docker-proxy*
-rwxr-xr-x 1 root root 0 Aug 3 22:08 docker-runc*
-rwxr-xr-x 1 root root 8962864 Aug 3 21:40 docker-volume-local-persist*
Installing from https://docs.docker.com/engine/installation/linux/docker-ce/binaries/
file $(which docker-runc):
/usr/bin/docker-runc: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=e3d80e183baf26a9d48c3f0435931d42aa1bf340, not stripped
lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 17.04
Release: 17.04
Codename: zesty
docker --version
Docker version 17.06.0-ce, build 02c1d87
dockerd --version
Docker version 17.06.0-ce, build 02c1d87
docker-containerd --version
containerd version 0.2.3 commit: cfb82a876ecc11b5ca0977d1733adbe58599088a
docker-containerd-ctr --version
ctr version 0.2.3 commit: cfb82a876ecc11b5ca0977d1733adbe58599088a
docker-init --version
tini version 0.13.0 - git.949e6fa
docker-runc --version
runc version 1.0.0-rc3
commit: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
spec: 1.0.0-rc5
Is this running on a non-Intel/ARM 64-bit Ubuntu? For example a Raspberry Pi or ARM64 CPU? This error:
shim error: fork/exec /usr/bin/docker-runc: exec format error
Would imply that either (a) the binary install on your machine is corrupted in some way, or (b) you are attempting to run a binary for a different architecture on your system.
Can you post the output of uname -a and file /usr/bin/docker-runc? That might help narrow down the source of your problem.
It looks like something related to aufs FS, What OS Do you use ? and Did you recently updated your machine ?
Update:
For CONFIG_MEMCG_SWAP_ENABLED: missing, CONFIG_RT_GROUP_SCHED: missing and warning: /proc/config.gz does not exist, searching other paths for kernel config ...
These are missing kernel configuration and flags, Please make sure you installed linux-image-extra-$(uname -r) linux-image-extra-virtual, First make sure you stopped docker daemon sudo systemctl stop docker and install these packages (contains extra driver that support containers and aufs check docker docs https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu):
sudo apt-get install \
linux-image-extra-$(uname -r) \
linux-image-extra-virtual
And update your grub GRUB_CMDLINE_LINUX_DEFAULT add thesecgroup_enable=memory swapaccount=1 to your /etc/default/grubconfiguration file then update your grub sudo update-grub check https://github.com/moby/moby/issues/4250 && https://github.com/moby/moby/pull/4251
For aufs problems there is another solution for modern dockers as docker moved from aufs to overlay and overlay2 is to configure your machine and apply overlay but make sure you backed up your docker images and containers as this fix might make you lose them check Unable to start Docker Service in Ubuntu 16.04