Is "java" available to acceptanceTests?

2020-06-06 Thread Kirk Lund
Does the image(s) we use for running acceptanceTest include "java"? I've
written some new AcceptanceTests for the LocatorLauncher and ServerLauncher
which pass locally but fail in precheckin in the cloud with
*java.io.IOException:
Cannot run program "java"*.

> Task :geode-assembly:acceptanceTest

org.apache.geode.launchers.LocatorLauncherWithPulseAndCustomLogConfigAcceptanceTest
> locatorLauncherUsesConfigFileInClasspathWithoutGeodePlugins FAILED
java.io.IOException: Cannot run program "java" (in directory
"/tmp/junit5795014123591460975"): error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
at
org.apache.geode.launchers.LocatorLauncherWithPulseAndCustomLogConfigAcceptanceTest.locatorLauncherUsesConfigFileInClasspathWithoutGeodePlugins(LocatorLauncherWithPulseAndCustomLogConfigAcceptanceTest.java:164)

Caused by:
java.io.IOException: error=2, No such file or directory
at java.lang.ProcessImpl.forkAndExec(Native Method)
at java.lang.ProcessImpl.(ProcessImpl.java:340)
at java.lang.ProcessImpl.start(ProcessImpl.java:271)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1107)
... 2 more


geode-assembly fails with SIGABRT

2020-06-06 Thread Kirk Lund
The docker image (or something related) seems to be broken for
geode-assembly. Anyone working on fixing this or know how to fix it?

https://concourse.apachegeode-ci.info/builds/163375

Something in the docker setup SIGABRTs...

> Task :geode-assembly:docker
free(): invalid pointer
SIGABRT: abort
PC=0x7fdda9240e97 m=0 sigcode=18446744073709551610
signal arrived during cgo execution

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x4afd50, 0xc420051cc0, 0xc420051ce8)
/usr/lib/go-1.8/src/runtime/cgocall.go:131 +0xe2 fp=0xc420051c90
sp=0xc420051c50
github.com/docker/docker-credential-helpers/secretservice._Cfunc_free(0x2670270)
github.com/docker/docker-credential-helpers/secretservice/_obj/_cgo_gotypes.go:111
+0x41 fp=0xc420051cc0 sp=0xc420051c90
github.com/docker/docker-credential-helpers/secretservice.Secretservice.List.func5(0x2670270)
/build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
github.com/docker/docker-credential-helpers/secretservice/secretservice_linux.go:96
+0x60 fp=0xc420051cf8 sp=0xc420051cc0
github.com/docker/docker-credential-helpers/secretservice.Secretservice.List(0x0,
0x756060, 0xc420012360)
/build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
github.com/docker/docker-credential-helpers/secretservice/secretservice_linux.go:97
+0x217 fp=0xc420051da0 sp=0xc420051cf8
github.com/docker/docker-credential-helpers/secretservice.(*Secretservice).List(0x77e548,
0xc420051e88, 0x410022, 0xc4200122b0)
:4 +0x46 fp=0xc420051de0 sp=0xc420051da0
github.com/docker/docker-credential-helpers/credentials.List(0x756ba0,
0x77e548, 0x7560e0, 0xc42000e018, 0x0, 0x10)
/build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
github.com/docker/docker-credential-helpers/credentials/credentials.go:145
+0x3e fp=0xc420051e68 sp=0xc420051de0
github.com/docker/docker-credential-helpers/credentials.HandleCommand(0x756ba0,
0x77e548, 0x7ffea9775e1d, 0x4, 0x7560a0, 0xc42000e010, 0x7560e0,
0xc42000e018, 0x40e398, 0x4d35c0)
/build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
github.com/docker/docker-credential-helpers/credentials/credentials.go:60
+0x16d fp=0xc420051ed8 sp=0xc420051e68
github.com/docker/docker-credential-helpers/credentials.Serve(0x756ba0,
0x77e548)
/build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
github.com/docker/docker-credential-helpers/credentials/credentials.go:41
+0x1cb fp=0xc420051f58 sp=0xc420051ed8
main.main()
/build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/secretservice/cmd/main_linux.go:9
+0x4f fp=0xc420051f88 sp=0xc420051f58
runtime.main()
/usr/lib/go-1.8/src/runtime/proc.go:185 +0x20a fp=0xc420051fe0
sp=0xc420051f88
runtime.goexit()
/usr/lib/go-1.8/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc420051fe8
sp=0xc420051fe0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/lib/go-1.8/src/runtime/asm_amd64.s:2197 +0x1

rax0x0
rbx0x7ffea9775420
rcx0x7fdda9240e97
rdx0x0
rdi0x2
rsi0x7ffea97751b0
rbp0x7ffea9775520
rsp0x7ffea97751b0
r8 0x0
r9 0x7ffea97751b0
r100x8
r110x246
r120x7ffea9775420
r130x1000
r140x0
r150x30
rip0x7fdda9240e97
rflags 0x246
cs 0x33
fs 0x0
gs 0x0


Re: Is "java" available to acceptanceTests?

2020-06-06 Thread Kirk Lund
Here's a link to the precheckin failure:
https://concourse.apachegeode-ci.info/builds/163281

On Fri, Jun 5, 2020 at 3:16 PM Kirk Lund  wrote:

> Does the image(s) we use for running acceptanceTest include "java"? I've
> written some new AcceptanceTests for the LocatorLauncher and ServerLauncher
> which pass locally but fail in precheckin in the cloud with 
> *java.io.IOException:
> Cannot run program "java"*.
>
> > Task :geode-assembly:acceptanceTest
>
> org.apache.geode.launchers.LocatorLauncherWithPulseAndCustomLogConfigAcceptanceTest
> > locatorLauncherUsesConfigFileInClasspathWithoutGeodePlugins FAILED
> java.io.IOException: Cannot run program "java" (in directory
> "/tmp/junit5795014123591460975"): error=2, No such file or directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
> at
> org.apache.geode.launchers.LocatorLauncherWithPulseAndCustomLogConfigAcceptanceTest.locatorLauncherUsesConfigFileInClasspathWithoutGeodePlugins(LocatorLauncherWithPulseAndCustomLogConfigAcceptanceTest.java:164)
>
> Caused by:
> java.io.IOException: error=2, No such file or directory
> at java.lang.ProcessImpl.forkAndExec(Native Method)
> at java.lang.ProcessImpl.(ProcessImpl.java:340)
> at java.lang.ProcessImpl.start(ProcessImpl.java:271)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1107)
> ... 2 more
>


Problem in rolling upgrade since 1.12

2020-06-06 Thread Alberto Gomez
Hi,

I have observed that since version 1.12 rolling upgrades to future versions 
leave the first upgraded locator "as if" it was still on version 1.12.

This is the output from "list members" before starting the upgrade from version 
1.12:

Name | Id
 | ---
vm2  | 192.168.0.37(vm2:29367:locator):41001 [Coordinator]
vm0  | 192.168.0.37(vm0:29260):41002
vm1  | 192.168.0.37(vm1:29296):41003


And this is the output from "list members" after upgrading the first locator 
from 1.12 to 1.13/1.14:

Name | Id
 | 

vm2  | 192.168.0.37(vm2:1453:locator):41001(version:GEODE 1.12.0) 
[Coordinator]
vm0  | 192.168.0.37(vm0:810):41002(version:GEODE 1.12.0)
vm1  | 192.168.0.37(vm1:849):41003(version:GEODE 1.12.0)


Finally this is the output in gfsh once the rolling upgrade has been completed 
(locators and servers upgraded):

Name | Id
 | 

vm2  | 192.168.0.37(vm2:1453:locator):41001(version:GEODE 1.12.0) 
[Coordinator]
vm0  | 192.168.0.37(vm0:2457):41002
vm1  | 192.168.0.37(vm1:2576):41003

I verified this by running manual tests and also by running the following 
upgrade test (had to stop it in the middle to connect via gfsh and get the gfsh 
outputs):
RollingUpgradeRollServersOnPartitionedRegion_dataserializable.testRollServersOnPartitionedRegion_dataserializable

After the rolling upgrade, the shutdown command fails with the following error:
Member 192.168.0.37(vm2:1453:locator):41001 could not be found.  Please 
verify the member name or ID and try again.

The only way I have found to come out of the situation is by restarting the 
locator.
Once restarted again, the output of gfsh shows that all members are upgraded to 
the new version, i.e. the locator does not show anymore that it is on version 
GEODE 1.12.0.

Anybody has any clue why this is happening?

Thanks in advance,

/Alberto G.


Re: geode-assembly fails with SIGABRT

2020-06-06 Thread Bill Burcham
Kirk: what happens when you run ./gradlew :geode-assembly:docker in your
local dev environment? Does it break the same way? If not, then I surmise
this may be due to a recent configuration change to the AWS AMI used for CI.

This bug report on Docker credentials helper has some stack traces that
look very similar to the one you provided above:

https://github.com/docker/docker-credential-helpers/issues/103

There are a number of people weighing in on that ticket with fixes.

On Sat, Jun 6, 2020 at 5:50 AM Kirk Lund  wrote:

> The docker image (or something related) seems to be broken for
> geode-assembly. Anyone working on fixing this or know how to fix it?
>
> https://concourse.apachegeode-ci.info/builds/163375
>
> Something in the docker setup SIGABRTs...
>
> > Task :geode-assembly:docker
> free(): invalid pointer
> SIGABRT: abort
> PC=0x7fdda9240e97 m=0 sigcode=18446744073709551610
> signal arrived during cgo execution
>
> goroutine 1 [syscall, locked to thread]:
> runtime.cgocall(0x4afd50, 0xc420051cc0, 0xc420051ce8)
> /usr/lib/go-1.8/src/runtime/cgocall.go:131 +0xe2 fp=0xc420051c90
> sp=0xc420051c50
>
> github.com/docker/docker-credential-helpers/secretservice._Cfunc_free(0x2670270)
>
> github.com/docker/docker-credential-helpers/secretservice/_obj/_cgo_gotypes.go:111
> +0x41
> 
> fp=0xc420051cc0 sp=0xc420051c90
>
> github.com/docker/docker-credential-helpers/secretservice.Secretservice.List.func5(0x2670270)
>
> /build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
> 
>
> github.com/docker/docker-credential-helpers/secretservice/secretservice_linux.go:96
> +0x60
> 
> fp=0xc420051cf8 sp=0xc420051cc0
>
> github.com/docker/docker-credential-helpers/secretservice.Secretservice.List(0x0
> ,
> 0x756060, 0xc420012360)
>
> /build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
>
> github.com/docker/docker-credential-helpers/secretservice/secretservice_linux.go:97
> +0x217
> 
> fp=0xc420051da0 sp=0xc420051cf8
>
> github.com/docker/docker-credential-helpers/secretservice.(*Secretservice).List(0x77e548
> ,
> 0xc420051e88, 0x410022, 0xc4200122b0)
> :4 +0x46 fp=0xc420051de0 sp=0xc420051da0
> github.com/docker/docker-credential-helpers/credentials.List(0x756ba0,
> 0x77e548, 0x7560e0, 0xc42000e018, 0x0, 0x10)
>
> /build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
> github.com/docker/docker-credential-helpers/credentials/credentials.go:145
> +0x3e
> 
> fp=0xc420051e68 sp=0xc420051de0
>
> github.com/docker/docker-credential-helpers/credentials.HandleCommand(0x756ba0
> ,
> 0x77e548, 0x7ffea9775e1d, 0x4, 0x7560a0, 0xc42000e010, 0x7560e0,
> 0xc42000e018, 0x40e398, 0x4d35c0)
>
> /build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
> github.com/docker/docker-credential-helpers/credentials/credentials.go:60
> +0x16d
> 
> fp=0xc420051ed8 sp=0xc420051e68
> github.com/docker/docker-credential-helpers/credentials.Serve(0x756ba0,
> 0x77e548)
>
> /build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/obj-x86_64-linux-gnu/src/
> github.com/docker/docker-credential-helpers/credentials/credentials.go:41
> +0x1cb
> 
> fp=0xc420051f58 sp=0xc420051ed8
> main.main()
>
> /build/golang-github-docker-docker-credential-helpers-cMhSy1/golang-github-docker-docker-credential-helpers-0.5.0/secretservice/cmd/main_linux.go:9
> +0x4f fp=0xc420051f88 sp=0xc420051f58
> runtime.main()
> /usr/lib/go-1.8/src/runtime/proc.go:185 +0x20a fp=0xc420051fe0
> sp=0xc420051f88
> runtime.goexit()
> /usr/lib/go-1.8/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc420051fe8
> sp=0xc420051fe0
>
> goroutine 17 [syscall, locked to thread]:
> runtime.goexit()
> /usr/lib/go-1.8/src/runtime/asm_amd64.s:2197 +0x1
>
> rax0x0
> rbx0x7ffea9775420
> rcx0x7fdda9240e97
> rdx0x0
> rdi0x2
> rsi0x7ffea97751b0
> rbp0x7ffea9775520
> rsp0x7ffea97751b0
> r8 0x0
> r9 0x7ffea9