I've got some desktops running Windows 7 that I'm trying to setup as Jenkins slaves. The slaves work if I connect using the command line provided on the slave status page, such as java -jar slave.jar -jnlpUrl http://jenkins-master.mycompany.com:8080/computer/slave1/slave-agent.jnlp -secret 42abcdef123456abef222ccc11. But if I connect using the java web start button on the status page it fails with an exception:
java.lang.NullPointerException
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I get the same error on 3 different slave machines. In all three cases I'm launching from a browser running on the slave machine.
I'd like to have the slaves running as a Windows service. I could set it up so the service issues the java command line that does work, but I'd prefer to use the service facilities provided by jenkins itself. Plus I'd simply like to understand why the web start method isn't working. How do I go about debugging this?
Related
I'm running Jenkins on a Windows Server 2012 which runs ok, but I can't restart Jenkins e.g. after updating plugins.
The error I get in the jenkins.err.log is
SEVERE winstone.Logger#logInternal: Container startup failed
java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Unknown Source)
at sun.nio.ch.Net.bind(Unknown Source)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:342)
Caused: java.io.IOException: Failed to bind to 0.0.0.0/0.0.0.0:8080
at org.eclipse.jetty.server.ServerConnector.openAcceptChannel(ServerConnector.java:346)
at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:308)
at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:236)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:396)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at winstone.Launcher.<init>(Launcher.java:187)
Caused: java.io.IOException: Failed to start Jetty
at winstone.Launcher.<init>(Launcher.java:189)
at winstone.Launcher.main(Launcher.java:362)
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 Main._main(Main.java:375)
at Main.main(Main.java:151)
So apparently the port that Jenkins was running on (8080) is still in use after the restart.
The server console gives me this:
Child process [5424 - C:\Program Files (x86)\Jenkins\jre\bin\java -Xrs -Xmx512m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dhudson.model.DirectoryBrowserSupport.CSP="sandbox; default-src 'none'; img-src 'self'; style-src 'self' 'unsafe-inline';" -jar "C:\Program Files (x86)\Jenkins\jenkins.war" --httpPort=8080 --ajp13Port=-1 --webroot="C:\Program Files (x86)\Jenkins\war"] finished with 1
I have checked which process is using port 8080 using netstat, but can't find anything.
I know I can change the port when starting Jenkins using the "httpPort"-flag. Doing so (e.g. changing the port to 8081) will work - until I restart Jenkins again, this time 8081 will be in use (and also 8080 and all other ports I've been using before). This can only be resolved by restarting the server, then 8080 (and all other ports) will be available again.
Both "solutions" (1. keep changing the port, 2. restarting the server) are just tedious workarounds for me as I have to inform all colleagues which port is currently in use all the time or let administration restart the server over and over again.
The flag "--ajp13Port=-1" is an attempt to get this fixed, I also tried disabling the "RunawayProcessKiller"-extension as suggested in another post, but both didn't change anything.
Any hint to get this fixed is much appreciated.
I'm currently running a derby DB instance created from version 10.13.1.1
I connect via the network mode (startNetworkServer) running on a redhat server.
I'm now wanting to upgrade to version 10.14.2.0
However, when trying to connect to the upgraded database, I receive an access denied "java.io.FilePermission" error.
Details:
I went and downloaded both version 10.13.1.1 and 10.14.2.0 onto my windows desktop.
A backup of the database is created using the following command: SYSCS_UTIL.SYSCS_BACKUP_DATABASE
I copied this backup to both the 10.13 and 10.14 folders.
Starting with my current version (13) i start the network server, and then use ij to connect to the database. This works fine, and i can see the tables. This validates my backup is fine.
connect 'jdbc:derby://localhost:1527/c:\Temp\13\database;create=false';
I then start my 14 versions network server, and then go to 14's ij. When I try to connect to the backup:
connect 'jdbc:derby://localhost:1527/c:\Temp\14\database;create=false';
I get the filePermission error:
ERROR XJ001: DERBY SQL error: ERRORCODE: 0, SQLSTATE: XJ001, SQLERRMC: java.security.AccessControlException
access denied ("java.io.FilePermission" "C:\Temp\updating_derby\threatadvisor" "read")
XJ001.U
Fair enough, I assume this is because i'm trying to connect to an older version, without having run the upgrade=true parameter. When I remove the create parameter, and add the upgrade parameter, it still fails with the same issue.
Ok, so perhaps I can't upgrade a DB via the network server, and I have to directly connect to the DB. From within my app, I use the following connection string:
jdbc:derby:C:/Temp/14/database;upgrade=true;
The app has the version 14 jar on the classpath, so should use it and upgrade. Which it does, the app starts normally and I see all the data. How do I know it upgraded? Because I tried to connect to this 14 database using 13 network server and ij, and it fails (as expected due to version).
So i'm done right? No, I once more try to connect to this now upgraded database via the network server, using ij and i once again get the java.io.FilePermission issue.
I went in and ensured the actual OS permissions on the folders and files inside the "database" folder are not just read-only. None are. Yet still it errors.
I've even tried running 14 network server on the redhat box (on a different port), and trying to connect to this db via ij and even there i get the file permission issue.
I'm really at a loss as to what to do next. Please help!
FYI, the full issue from the derby.log file:
Tue Jun 11 12:04:15 AEST 2019 : Apache Derby Network Server - 10.14.2.0 - (1828579) started and ready to accept connections on port 1527
Tue Jun 11 12:04:28 AEST 2019 Thread[DRDAConnThread_2,5,main] Cleanup action starting
java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\Temp\14\database" "read")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.io.File.exists(File.java:814)
at java.io.WinNTFileSystem.canonicalize(WinNTFileSystem.java:434)
at java.io.File.getCanonicalPath(File.java:618)
at org.apache.derby.impl.io.DirStorageFactory.doInit(Unknown Source)
at org.apache.derby.impl.io.BaseStorageFactory.init(Unknown Source)
at org.apache.derby.impl.io.DirStorageFactory.init(Unknown Source)
at org.apache.derby.impl.services.monitor.StorageFactoryService.privGetStorageFactoryInstance(Unknown Source)
at org.apache.derby.impl.services.monitor.StorageFactoryService.access$400(Unknown Source)
at org.apache.derby.impl.services.monitor.StorageFactoryService$12.run(Unknown Source)
at org.apache.derby.impl.services.monitor.StorageFactoryService$12.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derby.impl.services.monitor.StorageFactoryService.getCanonicalServiceName(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection$4.run(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derby.impl.jdbc.EmbedConnection.startPersistentService(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.(Unknown Source)
at org.apache.derby.jdbc.InternalDriver$1.run(Unknown Source)
at org.apache.derby.jdbc.InternalDriver$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derby.jdbc.InternalDriver.getNewEmbedConnection(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.connect(Unknown Source)
at org.apache.derby.impl.drda.Database.makeConnection(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
Cleanup action completed
EDIT 1
Now trying to setup the security.policy file as per this guide. However, after creating a new policy file based off the template in the demo directory, we can't even get derby to pick up our file.
When we try to run:
java -classpath "C:\Temp\14\lib\derby.jar;C:\Temp\14\lib\derbynet.jar;C:\Temp\14\lib\derbyclient.jar;C:\Temp\14\lib\derbytools.jar;C:\Temp\14\lib\derbyoptionaltools.jar" -Djava.security.manager -Djava.security.policy=C:\Temp\14\server.policy org.apache.derby.drda.NetworkServerControl start
We get the following error:
java.security.AccessControlException: access denied org.apache.derby.security.SystemPermission( "engine", "usederbyinternals" )
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at org.apache.derby.iapi.security.SecurityUtil.checkDerbyInternalsPrivilege(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.getMonitorLite(Unknown Source)
at org.apache.derby.iapi.services.property.PropertyUtil$2.run(Unknown Source)
at org.apache.derby.iapi.services.property.PropertyUtil$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derby.iapi.services.property.PropertyUtil.getMonitorLite(Unknown Source)
at org.apache.derby.iapi.services.property.PropertyUtil.getSystemProperty(Unknown Source)
at org.apache.derby.iapi.services.property.PropertyUtil.getSystemProperty(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.init(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.(Unknown Source)
at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
I know this line is in the policy file (and uncommented):
permission org.apache.derby.security.SystemPermission "engine", "usederbyinternals";
However, I don't think it is even picking up our policy file, as if we change our reference to a non-existing policy file, we still get the same error.
Thanks to #BryanPendleton for pointing me in the right direction. For the initial issue, it was indeed because we needed the server.policy file. His link was helpful:
db.apache.org/derby/docs/10.14/security/csecjavasecurity.html
The second issue which we were having was resolved by using the server.policy file template located here:
https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/security/rsecbasicserver.html
Instead of the one provided in the download (the one in the derby download didn't have as many jars mentioned in it). More to the point, the way we referenced the jars had to be tweaked. You will see all the examples were for unix format, whereas we were developing on a test windows PC. Therefore instead of something like (unix):
grant codeBase "file:///home/someone/derby/lib/derby.jar"
We needed to do:
grant codeBase "file:///C:/Temp/14/lib/derby.jar"
Note the additional '/' after 'file' - we had assumed it was merely "file://C:...."
There is another solution to the problem which is to use this code:
https://github.com/apache/hive/blob/master/core/src/test/java/org/apache/hive/hcatalog/DerbyPolicy.java
and use this:
Policy.setPolicy(new DerbyPolicy());
To get a policy set programmatically.
I'm trying to run sonarQube
Installing through cmd as Admin:
InstallNTService.bat
StartSonar.bat
--> Wrapper Started as Console
Launching a JVM...
Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
2016.03.25 21:09:40 INFO app[o.s.a.AppFileSystem] Cleaning or creating temp directory C:\sonarqube-5.4\temp
WrapperSimpleApp: Encountered an error running main:java.lang.RuntimeException: Failed to reset file system
java.lang.RuntimeException: Failed to reset file system
at org.sonar.process.monitor.Monitor.resetFileSystem(Monitor.java:125)
at org.sonar.process.monitor.Monitor.startProcesses(Monitor.java:105)
at org.sonar.process.monitor.Monitor.start(Monitor.java:99)
at org.sonar.application.App.start(App.java:51)
at org.sonar.application.App.main(App.java:110)
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.nio.file.AccessDeniedException: C:\sonarqube-5.4\temp\jffi837955644087697080.tmp
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source)
at java.nio.file.Files.delete(Unknown Source)
at org.sonar.process.FileUtils$CleanDirectoryFileVisitor.visitFile(FileUtils.java:151)
at org.sonar.process.FileUtils$CleanDirectoryFileVisitor.visitFile(FileUtils.java:135)
at java.nio.file.Files.walkFileTree(Unknown Source)
at org.sonar.process.FileUtils.cleanDirectoryImpl(FileUtils.java:123)
at org.sonar.process.FileUtils.cleanDirectory(FileUtils.java:60)
at org.sonar.application.AppFileSystem.createOrCleanDirectory(AppFileSystem.java:116)
at org.sonar.application.AppFileSystem.reset(AppFileSystem.java:73)
at org.sonar.process.monitor.Monitor.resetFileSystem(Monitor.java:122)
... 10 more
<-- Wrapper Stopped
I' getting these errors:
WrapperSimpleApp: Encountered an error running main:java.lang.RuntimeException: Failed to reset file system
java.lang.RuntimeException: Failed to reset file system
Caused by: java.nio.file.AccessDeniedException: C:\sonarqube-5.4\temp\jffi837955644087697080.tmp
Please Assist.
Kill the Java process and try deleting the temp folder contents again. Worked for me.
The user that is running SonarQube (look at the user details in the windows services screen) must have R/W rights on several sub-directories in C:\Sonarqube-6.X. We assigned R/W rights to the whole C:\Sonarqube-6.X directory tree. Before retrying you can delete the temp directory safely. It is also essential that you unblocked the SonarQube zip-file after download and before unzipping.
I had the same issue, but was unable to delete the temp directory because it was locked. I restarted my computer and fired up sonarQube and it started without a problem. I'm guessing when I last closed my SonarQube session some resource was still holding onto the temp folder and wouldn't release but I couldn't find a sonarqube process to kill off in the task manager.
You can follow below steps...Its work form me.
1: Stop the running sonar cmd window.
2: open Task manager and kill "Java Process" then manually delete temp folder.
3: Run Again
Thanks
Vinod
i aslo got the same problem
use the command
source ~/.bash_profile (2times)
then go and execute sonarqn
I am attempting to run tomcat as a service. I am able to run it succesfully when I specify just a startpath or just jvmoptions. However, if I have both I am receiving the following error:
2013-04-25 11:34:01 Commons Daemon procrun stderr initialized
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:236)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:426)
The commands I am running are as follows:
service.bat install WebServices
tomcat7 //US//WebServices --Startup=auto --DisplayName="Web Services"
tomcat7 //US//WebServices --StartPath="C:\Program Files\engine"
tomcat7 //US//WebServices --JvmOptions="-Xmx4g;-XX:PermSize=2048m;-XX:MaxPermSize=2048m"
As I stated, the service starts fine if I don't run the JvmOptions line, and it successfully writes log files to my startpath directory. Then if I don't include startpath it will also run correctly, and it just won't output to the startpath. The error only occurs when both variables are set.
The issue was that when I was changing the start path and assigning variables it was losing track of catalina home. So I added
-Dcatalina.home=apacheInstallLoc;-Dcatalina.base=apacheInstallLoc
to my JvmOptions and everything worked.
we have Sonar set up to run on a separate server. It does, and a client application (sonar-runner) can connect successfully to it. However, the run interrupts with the following exception:
Runner configuration file: C:\Program Files (x86)\sonar-runner-1.3\bin\..\conf\sonar-runner.properties
Project configuration file: C:\project\subproject\sonar-project.properties
Runner version: 1.3
Java version: 1.6.0_33, vendor: Sun Microsystems Inc.
OS name: "Windows 7", version: "6.1", arch: "x86"
Server: http://<serverip>:80
Work directory: C:\project\subproject\.sonar
Total time: 1:30.902s
Final Memory: 0M/15M
Exception in thread "main" org.sonar.batch.bootstrapper.BootstrapException: org.sonar.batch.bootstrapper.BootstrapException: Fail to download the file: http://<serverip>:80/batch/guava-10.0.1.jar
at org.sonar.batch.bootstrapper.Bootstrapper.downloadBatchFiles(Bootstrapper.java:164)
at org.sonar.batch.bootstrapper.Bootstrapper.createClassLoader(Bootstrapper.java:87)
at org.sonar.runner.Runner.createClassLoader(Runner.java:155)
at org.sonar.runner.Runner.execute(Runner.java:78)
at org.sonar.runner.Main.main(Main.java:61)
Caused by: org.sonar.batch.bootstrapper.BootstrapException: Fail to download the file: http://<serverip>:80/batch/guava-10.0.1.jar
at org.sonar.batch.bootstrapper.Bootstrapper.remoteContentToFile(Bootstrapper.java:113)
at org.sonar.batch.bootstrapper.Bootstrapper.downloadBatchFiles(Bootstrapper.java:159)
... 4 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.ChunkedInputStream.readAheadBlocking(Unknown Source)
at sun.net.www.http.ChunkedInputStream.readAhead(Unknown Source)
at sun.net.www.http.ChunkedInputStream.read(Unknown Source)
at java.io.FilterInputStream.read(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source)
at org.sonar.batch.bootstrapper.BootstrapperIOUtils.copyLarge(BootstrapperIOUtils.java:63)
at org.sonar.batch.bootstrapper.Bootstrapper.remoteContentToFile(Bootstrapper.java:109)
... 5 more
I can reproduce this with a normal browser. Retrieving the file opens the download manager, however, it takes up to 5 minutes until the file finally downloads (it's only 1.5 megs). Other files that are retrieved by the sonar-runner or using a browser do not have this problem.
The sonar logging doesn't seem to know that there is a problem. Downloads are not logged in the sonar.log file, neither successful ones nor the unsuccessful one. syslog doesn't contain any hints to problems.
had similar problem with sonar+php plugin and eset smart security. Had to disable filtering on 127.0.0.1 in filtering protocols section. It was happening randomly on different jars. It was happening on both solar ant task and solar runner
So, the solution was not something on the server, but rather a client-side problem. Kaspersky Endpoint Security seems to have a bug/feature that it needs to scan everything going over the network, and somehow this one JAR file triggered a multiple-minute-long delay while the file was being scanned.