Hudson slaves failing to start on Windows XP: java.net.SocketTimeoutException - hudson

I have bug troubles (re)starting Hudson slaves on Windows XP machines that are located on a different campus (not so close to the hudson server, still the network speed is decent and reliable - do get ~400-800 KB/s on test).
Hudson server is running on OS X under Tomcat.
hudson-slave.err.log:
Exception in thread "main" java.net.SocketTimeoutException: Accept timed out
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(Unknown Source)
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at hudson.remoting.Launcher.runAsTcpServer(Launcher.java:303)
at hudson.remoting.Launcher.run(Launcher.java:202)
at hudson.remoting.Launcher.main(Launcher.java:167)
hudson-slave.wrapper.log:
2010-10-11 12:22:18 - Started 3116
2010-10-12 00:52:11 - Starting javaw.exe -Xrs -jar "d:\.hudson\slave.jar" -tcp d:\.hudson\port.txt
2010-10-12 00:52:12 - Started 3312
2010-10-12 02:12:05 - Starting javaw.exe -Xrs -jar "d:\.hudson\slave.jar" -tcp d:\.hudson\port.txt
2010-10-12 02:12:05 - Started 1332
2010-10-12 02:36:05 - Starting javaw.exe -Xrs -jar "d:\.hudson\slave.jar" -tcp d:\.hudson\port.txt
2010-10-12 02:36:05 - Started 2972
2010-10-12 03:56:05 - Starting javaw.exe -Xrs -jar "d:\.hudson\slave.jar" -tcp d:\.hudson\port.txt
2010-10-12 03:56:05 - Started 632
Event log:
Event Type: Warning
Event Source: hudsonslave-d__.hudson
Event Category: None
Event ID: 0
Date: 10/12/2010
Time: 3:56:36 AM
User: N/A
Computer: GWATANAB370-XP
Description:
Child process [632 - javaw.exe -Xrs -jar "d:\.hudson\slave.jar" -tcp d:\.hudson\port.txt] terminated with 1
Another strange thing is that I see that slave.jar file is always incomplete. The one from the server is 131131 bytes long but the one downloaded to the client is always less than this.
On the node monitor the last step is Copying slave.jar and stays like this forever.
In case it wasn't obvious the node is configured to be started with Let Hudson control this Windows slave as a Windows service option. This seams to me the most reliable method that should be safe even if hudson server or client is rebooted.

I have good experience with installing a slave as a service and let the remote machine handle the service startup and shutdown. Master and slave find each other regardless of what server gets restarted. Works reliable and I don't need to supply a Administrator password to control the slave.
As you probably figured out, you need to update the slave together with the master. But I don't remember if I always did this. Meanwhile we switched the slaves to unix and I use the ssh feature. The slaves come only up when needed. So I can't really run a test with this.

Related

MySQL 8 does not use the provided config files

I am installing Galera 4 on top of MySQL 8 on Debian but can't make it work. Once I start first node with bootstrap command:
mysqld_bootstrap
it starts with the following options:
/usr/sbin/mysqld $$'$\'$\\\'--wsrep-new-cluster --wsrep-on\\\'\'' --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1
Problem is there is no pid file created and even though it appears to be running and I can't connect to the database.
There is nothing going to the log file either so I think it is ommiting the config files.
I have tried running config validator:
mysqld --validate_config
but it hangs on futex (checked with strace). In both cases it is not possible to kill mysqld normally and -9 option has to be used.
LXC is used to run this instance with following kernel:
Linux node01 4.15.18-26-pve #1 SMP PVE 4.15.18-54 (Sat, 15 Feb 2020 15:34:24 +0100) x86_64 GNU/Linux
The answer was pretty obvious after some investigation. No rsync used to sync the cluster was installed on the nodes so they can't sync together.

Openshift v3: after starting the SpringBoot / Mysql application the app is killed after a few secs

After building the app, the deployment process works. The SpringBoot (mysql) application is deployed and marked as the usual "Starting the application".
After a few seconds, there is a message saying it "kills" the application. Notice, I am just within the limits of my Openshift free quota.
What is the mesage? .../wildfly/bin/standalone.sh: line 307: 183 Killed "java" -D"[Standalone]"
See the line in bold.
On another time I see is that the application is started, I can even login, but then after a minute is is killed.
14:47:15,334 INFO [nl.xyz.Application] (ServerService Thread Pool --
66) Started Application in 26.49 seconds (JVM running for 57.227)
14:47:15,723 INFO [javax.enterprise.resource.webcontainer.jsf.config]
(ServerService Thread Pool -- 66) Initializing Mojarra 2.2.13.SP1
20160303-1204 for context '' /wildfly/bin/standalone.sh: line 307: 183
Killed "java" -D"[Standalone]" -server -XX:+UseParallelGC -Xms40m
-Xmx250m -XX:+AggressiveOpts -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dorg.apache.tomcat.util.LOW_MEMORY=true -DOPENSHIFT_APP_UUID= -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Djboss.node.name=solvedcaches-5-80fj7 -Djgroups.bind_addr=0.0.0.0 -Dorg.apache.coyote.http11.Http11Protocol.COMPRESSION=on "-Dorg.jboss.boot.log.file=/wildfly/standalone/log/server.log"
"-Dlogging.configuration=file:/wildfly/standalone/configuration/logging.properties"
-jar "/wildfly/jboss-modules.jar" -mp "/wildfly/provided_modules:/wildfly/modules" org.jboss.as.standalone
-Djboss.home.dir="/wildfly" -Djboss.server.base.dir="/wildfly/standalone" '-b' '0.0.0.0' '-bmanagement' '0.0.0.0'
The last 2 build failed due to a generic build failture. Strange, the code was hardly changed. It looks like rebuilding takes memory and is competing with the running application and vice versa. The last time I stopped the POD, then deployment was ok.
Thank you #Jiri Fialka for all your help, online / offline.
As you suggested, after configuring the memory over the 2 POD's the application is working fine. Now I use 410 Mb for Mysql and 600 Mb for SpringBoot was WAR on a Wildfly pod. Even SSH was added within minutes!.
I am enthusiastic about the new Openshift v3 facilities. Also the GUI and oc.

Gatling Runtime Exception from Jenkins :java.io.IOException .. An existing connection was forcibly closed by the remote host

I Get the below exception while I run the Gatling(version 2.2.5) Test through a Jenkins Job at 5 TPS - rampUsersPerSec(0.1) to 5 during(5 minutes),constantUsersPerSec(5) during(15 minutes), the exception starts after 15 mins of test run.
However, I do not see this exception while the test runs at 0.2 TPS - rampUsersPerSec(0.1) to 0.2 during(5 minutes),constantUsersPerSec(0.2) during(15 minutes)
The Jenkins( version 2.66 ) runs on Windows 7(64-bit OS), with 4 GB RAM on Tomcat.
Will this be the limitation and cause for this exception?
what's triggering this, how do I get this resolved ?
Is there any Gatling Jenkins Host(Load Generator) specification that I have to look for ?
Appreciate your inputs !
22:20:28.946 [DEBUG] i.g.h.a.AsyncHandler - Request
T013_GET_Updates' failed for user 601
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:221)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:899)
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:276)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:119)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:643)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:566)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:480)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:442)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:748)
It seems, the port you are using is already occupied. Take specific port for host or remote machine.
Cheers,
Peekay

Apache Drill: Failure setting up ZK for client

I am testing Apache Drill with a two server cluster.
Let's say their external IPs are:
1.1.1.1
2.2.2.2
I first setup Zookeeper to run on both, and when I do the status command I get positive response:
ZooKeeper JMX enabled by default
Using config: /opt/zookeeper-3.4.8/bin/../conf/zoo.cfg
Mode: leader
The way I have my zoo.cfg to get it working was like this:
Server 1:
// other default values omitted
clientPort=2181
server.1=0.0.0.0:2888:3888
server.2=2.2.2.2:2888:3888
Server 2:
// other default values omitted
clientPort=2181
server.1=1.1.1.1:2888:3888
server.2=0.0.0.0:2888:3888
Next I wanted to get Drill running with this cluster, so I modify the drill-override.conf file for the 2 servers as follows:
Server 1:
drill.exec: {
cluster-id: "test",
zk.connect: "1.1.1.1:2181,2.2.2.2:2181"
}
Server 2:
drill.exec: {
cluster-id: "test",
zk.connect: "2.2.2.2:2181,1.1.1.1:2181"
}
I can start a drillbit on both servers, and when I do status I get this response on both servers:
drillbit is running.
But when I then try to open the console via bin/drill-conf I get this stack trace:
Error: Failure in connecting to Drill: org.apache.drill.exec.rpc.RpcException: Failure setting up ZK for client. (state=,code=0)
java.sql.SQLException: Failure in connecting to Drill: org.apache.drill.exec.rpc.RpcException: Failure setting up ZK for client.
at org.apache.drill.jdbc.impl.DrillConnectionImpl.<init>(DrillConnectionImpl.java:159)
at org.apache.drill.jdbc.impl.DrillJdbc41Factory.newDrillConnection(DrillJdbc41Factory.java:64)
at org.apache.drill.jdbc.impl.DrillFactory.newConnection(DrillFactory.java:69)
at net.hydromatic.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:126)
at org.apache.drill.jdbc.Driver.connect(Driver.java:72)
at sqlline.DatabaseConnection.connect(DatabaseConnection.java:167)
at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:213)
at sqlline.Commands.connect(Commands.java:1083)
at sqlline.Commands.connect(Commands.java:1015)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
at sqlline.SqlLine.dispatch(SqlLine.java:742)
at sqlline.SqlLine.initArgs(SqlLine.java:528)
at sqlline.SqlLine.begin(SqlLine.java:596)
at sqlline.SqlLine.start(SqlLine.java:375)
at sqlline.SqlLine.main(SqlLine.java:268)
Caused by: org.apache.drill.exec.rpc.RpcException: Failure setting up ZK for client.
at org.apache.drill.exec.client.DrillClient.connect(DrillClient.java:208)
at org.apache.drill.jdbc.impl.DrillConnectionImpl.<init>(DrillConnectionImpl.java:151)
... 18 more
Caused by: java.io.IOException: Failure to connect to the zookeeper cluster service within the allotted time of 10000 milliseconds.
at org.apache.drill.exec.coord.zk.ZKClusterCoordinator.start(ZKClusterCoordinator.java:123)
at org.apache.drill.exec.client.DrillClient.connect(DrillClient.java:206)
... 19 more
apache drill 1.7.0
"start your sql engine"
Why would drill fail to connect to the ZK cluster, which is running just fine?
All ports are open between these two boxes.
Pre-Requisites
Prerequisites for starting drill in distributed mode:
(Required) Running Oracle JDK version 7
(Required) Running a ZooKeeper quorum
(Recommended) Running a Hadoop cluster
(Recommended) Using DNS
Configuration
As your server IP address:
Server 1 - 1.1.1.1
Server 2 - 2.2.2.2
Put same configuration in zoo.cfg in both Server 1 and Server 2
clientPort=2181
server.1=1.1.1.1:2888:3888
server.2=2.2.2.2:2888:3888
Similarly same configuration in drill-override.conf for both the servers
drill.exec: {
cluster-id: "test",
zk.connect: "1.1.1.1:2181,2.2.2.2:2181"
}
Starting Drill
Start drillbit on all the cluster nodes using
bin/drillbit.sh start
Using Drill
Web UI:
Open web UI using any node address. For example:
1.1.1.1:8047
Via Shell:
Fire bin/drill-localhost command and drill shell will appear.
Verify Installation
From drill shell or UI fire
SELECT * FROM sys.drillbits;
Drill lists information about the Drillbits that are running
Stopping Drill
Fire command
bin/drillbit.sh stop

Sonar Qube plugin problems with Flex

I'm having problems after an upgrade of my Sonar Qube :(
I installed the newest version (5.0) of Sonar Qube using an existing MySQL database. The previous Sonar Qube version was 3.7.4.
I'm using it to analyze a pure ActionScript project using the Flex plugin (Version 2.1).
The problems to me seem threefold:
Just starting the server and viewing previous analysis results I get gray
rects where code quality used to be indicated in shades of green etc.
After installing the Flex plugin using the Update Center this
remains.
Running the sonar-runner (version 2.4) I get two types of errors:
A whole lot of these:
23:35:01.572 DEBUG - Resource org.sonar.api.resources.Directory#46815882[key=path/to/folder] was found using deprecated key. Please update your plugin.
After which the analysis exits with this:
23:35:01.585 INFO - Sensor FlexSquidSensor done: 4508 ms
23:35:01.585 INFO - Sensor org.sonar.plugins.flex.cobertura.CoberturaSensor#1f96a21e...
23:35:01.585 INFO - No Cobertura report provided (see 'sonar.flex.cobertura.reportPath' property)
23:35:01.585 INFO - Sensor org.sonar.plugins.flex.cobertura.CoberturaSensor#1f96a21e done: 0 ms
23:35:01.585 INFO - Sensor SCM Sensor (wrapped)...
23:35:01.612 INFO - SCM provider for this project is: git
23:35:01.612 INFO - Retrieve SCM blame information...
23:35:01.615 INFO - 280 files to be analyzed
23:35:04.012 DEBUG - Updating semaphore batch-nl.manno:Earz
23:35:04.447 DEBUG - Release semaphore on project : org.sonar.api.resources.Project#4aa0b07b[id=60,key=nl.manno:Earz,qualifier=TRK], with key batch-nl.manno:Earz
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 14.293s
Final Memory: 15M/123M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
at org.sonar.runner.api.Runner.execute(Runner.java:100)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:53)
Caused by: java.lang.IllegalArgumentException: Expected one blame result per line but provider returned 3 blame lines while file src/nl/aloft/earz/core/modules/interval/Interval.as has 76 lines
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:88)
at org.sonar.batch.scm.DefaultBlameOutput.blameResult(DefaultBlameOutput.java:68)
at org.sonar.plugins.scm.git.JGitBlameCommand.blame(JGitBlameCommand.java:131)
at org.sonar.plugins.scm.git.JGitBlameCommand.access$000(JGitBlameCommand.java:44)
at org.sonar.plugins.scm.git.JGitBlameCommand$1.call(JGitBlameCommand.java:105)
at org.sonar.plugins.scm.git.JGitBlameCommand$1.call(JGitBlameCommand.java:102)
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:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
logout
Now I used to have more plugins installed than just Flex (including the mentioned Cobertura) but after installing those Sonar Qube fails to run at all without too much notification (needless to say the runner won't run either).
Can anyone shed some light on this?
Thanks in advance,
Manno
We already faced this issue with files having old Mac line ends (CR or \r). Git will not consider them as line ends so you end up having less lines in your blame than in your file.
You can "clean" your file using mac2unix utility.