Important Note on CentOS Java

Jenkins requires Java in order to run, however yum install jenkins does not enforce that java is already installed. Check to make sure that you already have java installed by running java -version. To further make things difficult for CentOS users, the default CentOS version of Java is not compatible with Jenkins. Jenkins typically works best with a Sun implementation of Java, which is not included in CentOS for licensing reasons.

If you get output similar to the following, it means you're using the default (GCJ) version of Java, which will not work with Jenkins:

To correct this, you may need to remove the GCJ version of Java and install a Sun-compatible version.

If you received the above output, uninstall the default java:

yum remove java

Then after you've uninstalled Java (or if you didn't have Java installed at all to begin with). You need to install a Sun-compatible version of Java. The easiest approach is using OpenJDK, which is available through the EPEL repository (alternatively you may install an official RPM directly from Oracle). To install OpenJDK run the following:

yum install java-1.8.0-openjdk

Depending on your version of CentOS, the package name for OpenJDK may differ. Use yum search openjdk to check for the name of the package. If OpenJDK is not found at all through yum, you probably need to install the EPEL yum repository. After installation, you should be able to get the following output for java -version:

Can anyone please share how to install jenkins as a service from Jenkins.war file. I am trying to install it on a Rhel 6.5 machine which sits behind a corporate firewall, so not able to access internet freely.

So if anyone could share how to install jenkins as service from its war file, it would be really helpful.(Note: I want to use the default Jetty server of jenkins rather than using tomcat to deploy the war file)

Not sure if these are exactly right, I'm not really a sysadmin. But, after some problems and working through the messages this is what I hit on that work. I really wanted to have the LTS release, not the latest build. I had to remove the cache (there may be a better way to clear it) to get yum to install 2.7.4 instead of 2.22.

We changed the user in /etc/sysconfig/jenkins per below instruction and also chown -R for all 3 locations.

The 'jenkins' user is created to run this service. If you change this to a different user via the config file, you must change the owner of /var/log/jenkins, /var/lib/jenkins, and /var/cache/jenkins.

We are unable to launch jenkins after this. Error "Starting Jenkins runuser: cannot set groups: Operation not permitted"

Anyone had this issue? While it does seem to be permission issue, not sure if which permission needs to be granted for "new" user here.
Starting Jenkins runuser: cannot set groups: Operation not permitted

Was there a major change in yesterday's 2.80 RPM-release? I launched a new Jenkins installation and, instead of the first-login prompting me for the string from the initialAdminPassword file, it let me straight into the application's privileged interface with no credential-prompting. When I explicitly rolled back to 2.79, the expected "secured by default" (credentialed) login was in place.

Fortunately, this was a pre-upgrade testing installation (in an isolated network) and not internet-exposed, but it meant we couldn't take the chance upgrading our production Jenkins from 2.76 to 2.80.

Hi, I have installed jenkins as per the given instruction in el7.x86_64 and tried launching jenkins with http://localhost:8080; But i dont have any default user id to login and secrets folder for InitialAdminpassword is not created under /root/.jenkins/

Ever since I filed the bug for 2.80, we've been experiencing intermittent issues with the `initialAdminpassword` file getting created. When it first cropped up, again, we had been running for a few weeks on 2.82 and were attempting to install 2.89 on a parallel system. We got the no `initialAdminpassword` file and assummed there'd simply been another regression. So, we blew the system away and did an explicit install of 2.88 with the intention of upgrading that install to 2.89 (or normal "upgrade" method is parallel deployment with a migration of data from old Jenkins install to new). That upgrade worked as expected, so we re-ran the procedures to verify process-validity for the Ops staff to execute. This time, 2.88 failed to create the `initialAdminpassword` file ...but a straight install of 2.89 worked. So, we did four more installs straight to 2.89: three failed; one succeeded. Similar results when 2.90 became available the next day.

Didn't update this bug or file a new one since it wasn't 100% reproducible nor manifesting at a specific version-level. Best I can suggest is keep reinstalling until it works as expected. Open a bug if you can find something repeatable you can identify.

by chance, do you have SELinux turned on? if you do, did you open up SELinux to allow Jenkins to read/write everywhere that it needs access to on the filesystem. SELinux might be blocking Jenkins from using areas of the local filesystem by default