Jenkins stuck at editing/creating nodes - jenkins

I created a slave node and ran a pipeline successfully but after that unable to configure the node. I've tried restarting Jenkins using the weburl as well as the shell. At this point, its stuck at creating a new Node or even when configure is clicked. The page just never opens. Deleting an existing node worked however.
Even the Mutli-Slave config plugin runs into the same problem. I'm guessing some data corruption? It would be a shame to reinstall Jenkins and redo the awful amount of configuration. Any ideas?
I was just beginning to like Jenkins.
PS: Editing the master node works. Using Jenkins 2.5.
EDIT:
I manually created a folder for a node under JENKINS_HOME/nodes and copied a config.xml for the node from some other server. The node appears in the list after server restart but still the option to Configure it hangs forever.

After wasting a lot of time I finally fixed the issue by downgrading Credentials plugin to the previous version: 1.28. Earlier today I had upgraded to the available latest 2.0.
Looks like others also hit the same problem today: https://github.com/jenkinsci/credentials-plugin/issues/49

Related

Jenkins detecting more than one instance

I realize that this question has been asked before but I feel like my case is different.
About five hours after I launch jenkins I sometimes see this message appear when loading the jenkins administrator panel:
Jenkins detected that you appear to be running more than one instance of Jenkins that share the same home directory '’. This greatly confuses Jenkins and you will likely experience strange behaviors, so please correct the situation."
This is strange, it happens every time I launch it, eventually making Jenkins unusable. I installed Jenkins via homebrew and launch is via the jenkins CLI. I manually do this so I don't see how it's possible that Jenkins launches twice.
I reinstalled Jenkins after completely removing it. Still no luck.
Anyone have any issues like this before?
I also had a similar problem and solved it with following checks:
Check if another java process is running which runs jenkins e.g. in unix using top
If you're using tomcat, search for a second instance of tomcat having the jenkins.war exploded somewhere
Could be helpful to just have one version of java installed

Jenkins Service vs Jenkins Jar File Permission

I have Jenkins 1.6 installed as a service on a CentOS machine.
At some point in the past the service stopped/crashed/? and Jenkins was restarted from the command line, java -jar jenkins.war, as the root user.
While it was running as root some plugins were updates/installed, and jobs created created/ran. Any new files created are now owned by the root user/group and not by the jenkins user/group.
Meaning, when the service was restarted Jenkins could not read these files. Resulting in plugins not running and most jobs not being loaded.
Manually restoring the permissions(chown, chgrp) to the plugins solves the plugin related issues.
For the jobs it's easy to spot new ones and fix them. Any existing ones that were re run and created new files are more difficult to find.
Then there may be other files which the Jenkins server created, not as part of a job or plugin which need to be changed. The errors are not always obvious, and crop up slowly over time.
Am I better adding the jenkins user to the root group? could this cause issues?
Or manually changing the permissions, hope i got them all! And fix others that come up?
Any suggestions appreciated.
In the end we manually changed the file permissions back to Jenkins. There were some immediate jobs that failed in the following days. And a few which only came up a few months later.
For the most part it worked well.

Revert to original configuration in Jenkins

I have a Jenkins server hosted, which has a master node and couple of other slave configurations. Last night, the job that triggers the matrix based build configuration failed. I did a restart and performed clean up jobs via Jenkins but none of those fixed the issue. The initial error that was logged was:
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel
hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel
Following which I performed a reload configuration from disk,followed by a manual restart via <jenkins_job_url>/restart, which even worsened the build system. The master went offline due to unavailability of space in /tmp folder, which I fixed by cleaning up the space. Following which I observed that the original slave server configuration is no longer seen. I had slave-0 and slave-1 still there, but slave-2 was no longer present. Instead, it got replaced with slave-3 configuration. Now the slave 0's and 1's seems to be working fine. However, slave 3's build are failing due to Failed to mkdirs. Is there a way I could revert back to the original configuration from where I started, since the steps I performed seems to make sense initially, but I had no idea it had so many repercussions? Any help is appreciated.
UPDATE1: I guess I should have used some of the configuration backup plugins available in Jenkins, but is there some specific directory other than $JENKINS_HOME where these configurations gets stored?
You should always backup ${JENKINS_HOME} before doing major changes.
Even better is to have a job based on time trigger that will do this for you once in a while.
Other than that - only physically restoring the hard drive to a previous state will get back your old configs. Once a config is overwritten in Jenkins - it is gone. Except when you are using Job Config History plugin. Though keeping manually created backups is better in my opinion: where's the insurance that JobConfigHistory won't disappear along with the job configs? :)
Aside from that, the mentioned plugin tracks system config too.
As mentioned by #Zloj, there is no easy way to repair once the changes gets overwritten. I ended up fixing the issues by deleting the slaves that were not working, remapping the existing builds to the newer slaves that I created via Copy of the existing slaves that were working, reducing the number of builds(by removing the ones from the matrix that aren't required) and finally, taking a backup via https://wiki.jenkins-ci.org/display/JENKINS/thinBackup plugin and backing up the configuration at Stash :)
for windows just delete .jenkins folder in your home directory. This will revert you to the original settings.
We have been using SCM Sync Configuration plugin and that has saved our butt many times. It stores all job configuration including global config in bitbucket. But the latest plugin will say that its no longer maintained. but I was able to pull the source code from github and rebuild it ourselves.
one word of caution...don't use global variables for storing passwords and keys...this plugin will sync them all to github. Strictly use Jenkins Credentials.

Jenkins slave agent service do not work since java update (which removed medium security level)

Situation:
Yesterday morning, all of our Slaves had problems (because thanks to Java, which removed the medium security level, the Jenkins slave agent could not be launched anymore). Java then started blocking all Jenkins slave agent.jlnp, we had to add on every slave an exception for our jenkins server, so the slave application can be launched. This was annoying but now they work. (was there an easier solution?)
Few slaves had Jenkins installed as a service (to be launched automatically on startup). However, since yesterday, they do not launch anymore, and we cannot find why. It probably has to do with the security from Java.
Someone has any idea?
You need to update jenkins reference to Java. It is in file C:\Jenkins\jenkins-slave.xml (or whereever is your Jenkins folder). When you updated Java Jenkins no longer knows where to find new version
Mine looks something like this.
<executable>C:\Program Files (x86)\Java\jre1.8.0_91\bin\java.exe</executable>
I made it works with the following steps:
1-) Uninstalling service
2-) Reboot
3-) Installing service
4-) Reboot

Jenkins Update Loses Old Jobs

I am on a redhat linux box. I recently updated Jenkins to version 1.509 only to find that after doing so it has "forgotten" two of my jobs/projects. The jobs can still be found on my Jenkins machine under /var/lib/jenkins/jobs, but they no longer show up in the Jenkins GUI. I attempted to re-create them based off the configuration file I have, but I am not confident I have totally re-created the functionality they had.
I also tried to copy the job and or rename it hoping that would get jenkins to see it, but no luck. I had tried cp -r /var/lib/jenkins/jobs/JOB1 /var/lib/jenkins/jobs/JOB2. I also restarted the service a number of times. Finally I updated all of my plugins on the off chance that was somehow related.
So my question is "How can I get Jenkins to notice these jobs?" or failing that "can I run these jobs from in the terminal?"
NOTE: I am not discouraging others from upgrading Jenkins. After I upgraded Jenkins did complain about a number of things which I didn't pay enough attention to which I believe got me into this mess in the first place.
If I were you, I would try the Jenkins CLI (from $JENKINS_URL/cli) and use the create-job command and feed the job configuration file to the cli's stdin.
If that does not help, I would inspect Jenkins log files (you are saving stdout and stderr of Jenkins somewhere, right?) for any errors or clues. If the job failed to load because of some tag that you can guess is provided by a plugin, try to remove that part from the config file.
If that does not help, I would upgrade Jenkins. I think there might be some fixes related to this in the LTS version changelog since 1.509.
And above all... if I were you, I would start making backups of the job configuration files.
I regularly back up the global config.xml, all the job config.xml files and all the plugins. Using these I can set up my Jenkins from scratch. And I do that to set up a test instance where I try any plugin or Jenkins core upgrade. If I see no problems after running a few of the trickiest builds, I know I can upgrade the production instance with much more confidence.

Resources