Jenkins fails to restart - continuous-integration

I was working on granting permission on Jenkins, I edited org.jenkins-ci.plist file in order to grant permission. Then restarted Jenkins by using java -jar jenkins-cli.jar -s https://localhost:8080
The webpage gave me this error.
org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException
at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
at jenkins.model.Jenkins.executeReactor(Jenkins.java:889)
at jenkins.model.Jenkins.<init>(Jenkins.java:794)
at hudson.model.Hudson.<init>(Hudson.java:81)
at hudson.model.Hudson.<init>(Hudson.java:77)
at hudson.WebAppMain$2.run(WebAppMain.java:217)
Caused by: java.lang.Error: java.lang.reflect.InvocationTargetException
at hudson.init.InitializerFinder.invoke(InitializerFinder.java:124)
at hudson.init.InitializerFinder$TaskImpl.run(InitializerFinder.java:184)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at jenkins.model.Jenkins$7.runTask(Jenkins.java:878)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at hudson.init.InitializerFinder.invoke(InitializerFinder.java:120)
... 8 more
Caused by: java.lang.NullPointerException
at org.jenkinsci.main.modules.sshd.SSHD.init(SSHD.java:144)
... 13 more
Since then I can't even use Jenkins-CLI nor jenkins itself.
What should I do to fix this?
And What should I do to avoid having the same errors when I need to change permission and restart jenkins in the future?
Thanks in advance
P.S. I'm using Mac OS Mountain Lion 10.8, and using Jenkins 1.474

Probably reported bug in jenkins. check here, you can revert your changes and/or try to older version of jenkins.

I had a similar error on Debian...
For Jenkins adding & granting permissions to Jenkins users
When enabling security on jenkins make sure you check
- "enable sign up", or something like that
- the option to store users, for example "jenkins own database"
- make sure that anonymous user have minimum read permission
Grant Jenkins permission on PC
Must say that I don't know the directory structure on Mac, but if it's similar to Linux...
- you should have a file called jenkins, on Linux is in /etc/sysconfig or /etc/default and in this file change JENKINS_USER to whatever user you want.But you must be sure that that user exists on PC, on Linux the user must be in /etc/passwd
change permissions to Jenkins home,webroot and logs, on Linux with:
chown -R user:user /var/lib/jenkins
chown -R user:user /var/cache/jenkins
chown -R user:user /var/log/jenkins
PS: I gave the Linux examples because it's easily to explain, again I don't have experience on Mac.
But it should work...

Trying to delete the folder contents and then refresh your website with your local host address,then you will see some unlock tip with the password appear in the terminal. Then go ahead to reinstall your plugins . Hope will help you!

Related

SonarQube - Temp directory is not writable [duplicate]

This question already has answers here:
SonarQube - Unable to load the Wrapper's native library 'wrapper.dll'
(5 answers)
Closed 3 months ago.
I'm installing SonarQube v5.0.1.
I'm running Windows Server 2012 64-bit, Java 1.8 64-bit, and the SonarQube windows-x86-64 wrapper.
SonarQube keeps throwing the following error:
WrapperSimpleApp: Encountered an error running main: java.lang.IllegalStateException: Temp directory is not writable: C:\Windows\system32\config\systemprofile\AppData\Local\Temp\
java.lang.IllegalStateException: Temp directory is not writable: C:\Windows\system32\config\systemprofile\AppData\Local\Temp\
at org.sonar.process.MinimumViableSystem.checkWritableDir(MinimumViableSystem.java:60)
at org.sonar.process.MinimumViableSystem.checkWritableTempDir(MinimumViableSystem.java:52)
at org.sonar.process.MinimumViableSystem.check(MinimumViableSystem.java:45)
at org.sonar.application.App.main(App.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java:240)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: The system cannot find the path specified
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(Unknown Source)
at org.sonar.process.MinimumViableSystem.checkWritableDir(MinimumViableSystem.java:57)
... 9 more
<-- Wrapper Stopped
Why does SonarQube keep trying to write to C:\Windows\System32\config\systemprofile\AppData\Local instead of C:\Windows\SysWOW64\config\systemprofile\AppData\Local?
To get rid of this error in previous installations, I've had to create a Temp folder in C:\Windows\System32\config\systemprofile\AppData\Local and fiddle with the read/write settings and or permissions to get SonarQube to stop complaining.
UPDATE: This is a huge problem, because I can't start SonarQube as a Windows Service. What's weird is that I already had SonarQube installed and running as a Windows Service. Today, I stopped the service, and now I can't start the service anymore. I've set the Temp folder's permissions to be not Read-Only and so that Everyone has Full Control (not ideal, I know...)
Still, the Temp error prevents SonarQube from starting.
This can also be fixed by setting the java.io.tmpdir java property to a writable directory.
e.g., in conf/wrapper.conf change
wrapper.java.additional.1=-Djava.awt.headless=true
to
wrapper.java.additional.1=-Djava.awt.headless=true -Djava.io.tmpdir=E:/sonarqube-5.1/temp
I had the same error in my sonar log when trying to start the service after I had installed it.
I had JAVA_HOME and x64 all correctly set up.
I managed to resolve the issue in the log above by changing the 'Log On As' for the installed service to 'NETWORK SERVICE' (without a password), then started the service. By default it had set the Log On As to Local System.
Probably another thing worth mentioning is if you're setting up SonarQube for the first time it may be best to get the website working before installing the service, otherwise debugging is a bit of a pain.
I had the same issue today with sonarqube 5.6 and Windows Server 2008 R2. Nothing of the above worked for me but what fixed the issue was defining a system variable TMPDIR pointing to another temp-directory e.g. C:\TMP
I had the same error when running some sonar analysis.
It turned out that in wrapper.conf I had to add
set.TMPDIR=c:/tmp
with path to the existing tmp directory and of course service needed to be reinstalled (UninstallNTService.bat / InstallNTService.bat)
In case of Windows (specifically Windows 10), delete the file under temp folder [under sonar folders] and run startSonar.bat. It should work.

Jenkins Plugin with proxy

I am have a Jenkins CI with the following configuration:
Tomcat on Open SUSE [openSUSE 13.1 (x86_64)] [Jenkins v1.532.3]
Java version "1.7.0_51" [OpenJDK Runtime Environment (IcedTea 2.4.4) (suse-24.13.5-x86_64)].
I am positive that I have my proxy configured correctly. But when I try to download a plugin or update a plugin on Jenkins. I get this error
Git Client Plugin
Failure -
hudson.util.IOException2: Failed to download from http://updates.jenkins-ci.org/download/plugins/git-client/1.8.1/git-client.hpi
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:794)
.
.
Caused by: java.net.ProtocolException: Server redirected too many times (20)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
.
.
.
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:764)
... 7 more
Caused by: java.net.ProtocolException: Server redirected too many times (20)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1636)
But I am able to do a Curl or a wget to the actual URL/URI to download the plugin
Thanks for your help and feedback
I don't think, that this is still relevant, but may be could help to someone else..
I had a similar issue after I changed my password. I checked different proxies and each time had the same issue. Now that I have changed the password again to have more standard symbols, the issues is immediately gone.
So it seems, that sometimes there can be just some problem with some special characters in the password.
Hope that could help someone.
Best Regards,
Viacheslav

How do I fix my SVN checkout on my Jenkins Slave?

I have spent a few days trying to get Jenkins working with svn.
On the master, when I configure the svn url, it validates the URL.
I can do a checkout manually, and am running the slave as the same user as I did the test manual checkout.
I have tried selecting all the different versions of svn on the jenkins config page.
I have checked that entering the incorrect creds on the subversion enterCredential page results in an error, and entering the correct creds allows it to pass.
We are using basic svn auth over http (on port 8080).
The URL validation in the job config passes okay, but the job running on the slave still throws the below exception.
From my various readings of information gleened from the net I am pretty sure this is an authentication issue.
The slave is a Mac OS X, the master is a Windows Server 2008.
Jenkins in running 1.504 (Tried with 1.502). We are using svn 1.6.
Here is the exception:
Building remotely on Mac OS Test Node in workspace /Users/buildmachine/jenkins/xcode
hudson.util.IOException2: remote file operation failed: /Users/buildmachine/jenkins/xcode at hudson.remoting.Channel#1695eeb:Mac OS Test Node
at hudson.FilePath.act(FilePath.java:861)
at hudson.FilePath.act(FilePath.java:838)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1342)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:683)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:588)
at hudson.model.Run.execute(Run.java:1568)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: java.io.IOException: Remote call on Mac OS Test Node failed
at hudson.remoting.Channel.call(Channel.java:681)
at hudson.FilePath.act(FilePath.java:854)
... 11 more
Caused by: java.lang.NoSuchMethodError: org.tmatesoft.svn.core.wc.SVNBasicClient.getOperationsFactory()Lorg/tmatesoft/svn/core/wc2/SvnOperationFactory;
at hudson.scm.SvnClientManager.wrapUp(SvnClientManager.java:46)
at hudson.scm.SvnClientManager.getUpdateClient(SvnClientManager.java:67)
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:71)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Finished: FAILURE
I had to remove the newer jar as well:
cd /var/lib/jenkins/plugins/subversion/WEB-INF/lib
mv svnkit-1.7.10-jenkins-1.jar /tmp
/etc/init.d/jenkins restart and it worked! Great Find!
Found the problem..
There was an old svnkit-1.3.6.1-jenkins-2.jar in C:\Program Files (x86)\Jenkins\plugins\subversion\WEB-INF\lib
Shutting down jenkins and deleting this file solved the issue.

javax.security.auth.login.LoginException: Login failed

I'm trying to run a hadoop job (version 18.3) on my windows machine but I get the following error:
Caused by: javax.security.auth.login.LoginException: Login failed: CreateProcess: bash -c groups error=2
at org.apache.hadoop.security.UnixUserGroupInformation.login(UnixUserGroupInformation.java:250)
at org.apache.hadoop.security.UnixUserGroupInformation.login(UnixUserGroupInformation.java:275)
at org.apache.hadoop.mapred.JobClient.configureCommandLineOptions(JobClient.java:557)
... 3 more
The same job works fine in an another windows machine. Do I have may be something wrong in the settings variabls? How can I fix this problem?
Maybe bash is not available on your PATH?
Do you have Cygwin installed correctly?
I really like this tutorial by Vlad Korolev to set up Hadoop on Windows.

Hudson as service on Windows - file system permissions

For some months we've run Hudson on a Windows XP "server" under a user account. This means someone manually logs in and starts Hudson via a .bat file (that sets up a few environment variables, then runs java -jar hudson.war)
However a few recent power cuts have resulted in the requirement to have Hudson start automatically at the time the server boots up. So I've turned to looking at Hudson running as a Windows Service. This would allow Hudson to start automatically with Windows, and would not require a specific user account.
I've managed to install it as a service, and I've changed hudson.xml so that the batch file is run rather than java directly. I do this because we build with git on Cygwin and SHELLOPTS=igncr must be set before bash starts java/Hudson.
The service seems to start properly, and the web interface is present and functional. However, it appears that the user that Hudson is now running under is unable to write/modify existing jobs in C:\hudson:
FATAL: Could not checkout 4a121704f178123c36f6ab4e861b3c771953b187
hudson.plugins.git.GitException: Could not checkout 4a121704f178123c36f6ab4e861b3c771953b187
at hudson.plugins.git.GitAPI.checkout(GitAPI.java:382)
at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:529)
at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:521)
at hudson.FilePath.act(FilePath.java:676)
at hudson.FilePath.act(FilePath.java:660)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:521)
at hudson.model.AbstractProject.checkout(AbstractProject.java:833)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266)
at hudson.model.Run.run(Run.java:948)
at hudson.model.Build.run(Build.java:112)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:118)
Caused by: hudson.plugins.git.GitException: Error performing c:\cygwin\bin\git.exe checkout -f 4a121704f178123c36f6ab4e861b3c771953b187
at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:302)
at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:276)
at hudson.plugins.git.GitAPI.checkout(GitAPI.java:380)
... 12 more
Caused by: hudson.plugins.git.GitException: Command returned status code 1: error: git checkout-index: unable to create file .gitignore (Permission denied)
error: git checkout-index: unable to create file .gitmodules (Permission denied)
error: git checkout-index: unable to create file Makefile (Permission denied)
I'm not really a Windows sort of person, but I thought perhaps if I added "Full Access" Security permissions to C:\hudson for the user "LOCAL_SERVICE" then that might fix it. Alas, it did not. I also tried full permissions for the user "Everyone" but that also did not solve the problem.
What am I missing here? Is there any way to allow a process running as a Service unfettered access to a subdirectory on a local disk?
How about you change the user that the service is running as. So create a new "technical" user account whose password nobody knows (except an envelope in your safe) and make this user the owner of all your hudson job folders. This also has the advantage that you can take permissions away from hudson. This way a Hudson job can not act as an admin on your windows machine.
The advantage of a service compared to a scheduled job is, that it restarts when it crashes.
Instead of running it as a service, maybe you should use Task Scheduler to set the process to run at logon, then have the user account auto-login. This is probably going to be much less hassle than dealing with service permissions, especially if you have to communicate with other machines.

Resources