RFR(S): 8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as 'Unknown'

[Bob Vandette]

> On Aug 13, 2019, at 2:57 PM, mikhailo.seledtsov at oracle.com wrote:
> 
> Hi Bob,
> 
>   The workdir (JTwork/scratch) is created with the "test user" permissions. Let me try to place the "signal" file in /tmp instead, since /tmp should normally have a 777 permission on Linux.

Aren’t you creating a file inside a docker container and then checking for its existence outside of the container?
Isn’t the root user running inside the container?

Both processes don’t see the same /tmp right?   So that shouldn’t help.

If scratch has 777 permissions, anyone can create a file.  You have to be careful that you can clean up the
file from outside the container.  I’d make sure to create it with 777.

Bob.

> 
> If this works, I will have to add some unique number to the file name, perhaps a PID of a child process.
> 
> I will try this, and let you know how it works.
> 
> 
> Thank you,
> 
> Misha
> 
> On 8/13/19 6:34 AM, Bob Vandette wrote:
>> Sorry, I just looked at the webrev and you are trying the approach I suggested.  I thought you
>> were trying to use file change notification.
>> 
>> Where does the workdir get created?  Does it have 777 permissions?
>> 
>> Bob.
>> 
>> 
>>> On Aug 13, 2019, at 9:29 AM, Bob Vandette <bob.vandette at oracle.com> wrote:
>>> 
>>> What if you just poll for the creation of the file waiting some small amount of time between polling with a maximum timeout.
>>> 
>>> Bob.
>>> 
>>> 
>>>> On Aug 12, 2019, at 8:22 PM, mikhailo.seledtsov at oracle.com wrote:
>>>> 
>>>> Unfortunately, this approach does not seem to work on many of our test cluster machines. The creation of a "signal" file results in "PermissionDenied".
>>>> 
>>>> The possible reason is the selinux configuration, or some other permission related stuff. The container tries to create a new file on a mounted volume on a host system, but host system denies it. I will look a bit deeper into this, but I think this type of issue can be encountered on any automated test system. Hence, we may have to abandon this approach.
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Misha
>>>> 
>>>> 
>>>> On 8/12/19 3:59 PM, mikhailo.seledtsov at oracle.com wrote:
>>>>> Here is an updated webrev: http://cr.openjdk.java.net/~mseledtsov/8228960.01/
>>>>> 
>>>>> I am using a simple file-based mechanism to communicate between the processes. The "EventGeneratorLoop" process creates a specific "signal" file on a shared mounted volume, while the main test process waits  for the file to exist before running the test cases.
>>>>> 
>>>>> Passes on Linux-x64 Docker-enabled host. Testing in the test cluster is in progress.
>>>>> 
>>>>> 
>>>>> Thank you,
>>>>> 
>>>>> Misha
>>>>> 
>>>>> On 8/7/19 5:11 PM, David Holmes wrote:
>>>>>> On 8/08/2019 9:04 am, Mikhailo Seledtsov wrote:
>>>>>>> Hi Severin, Bob,
>>>>>>> 
>>>>>>>   Thank you for reviewing the code.
>>>>>>> 
>>>>>>> On 8/7/19, 11:38 AM, Bob Vandette wrote:
>>>>>>>> Can’t you come up with a better way of synchronizing the test by possibly writing a
>>>>>>>> file and waiting for it to exist with a timeout?
>>>>>>> I will try out this approach.
>>>>>> This seems like a fundamental problem with jcmd - so cc'ing serviceability-dev.
>>>>>> 
>>>>>> But I'm pretty sure they recently addressed a similar issue with the premature sending of the attach signal?
>>>>>> 
>>>>>> David
>>>>>> -----
>>>>>> 
>>>>>>> Thanks,
>>>>>>> Misha
>>>>>>>> Isn’t there a shared volume between the two
>>>>>>>> processes?
>>>>>>>> 
>>>>>>>> We’ve been fighting test reliability for a while now.  I can only hope we’re getting
>>>>>>>> to the end.
>>>>>>>> 
>>>>>>>> Bob.
>>>>>>>> 
>>>>>>>>> On Aug 7, 2019, at 2:18 PM, Severin Gehwolf<sgehwolf at redhat.com>  wrote:
>>>>>>>>> 
>>>>>>>>> Hi Misha,
>>>>>>>>> 
>>>>>>>>> On Tue, 2019-08-06 at 20:17 -0700, mikhailo.seledtsov at oracle.com wrote:
>>>>>>>>>> Please review this change that fixes a container test TestJcmdWithSideCar.
>>>>>>>>>> 
>>>>>>>>>> My investigation indicated that a root cause for this failure is:
>>>>>>>>>> JCMD -l shows 'Unknown' for class name because the main class has not
>>>>>>>>>> been loaded yet.
>>>>>>>>>> The target test JVM has started, it is initializing, but has not loaded
>>>>>>>>>> the main test class.
>>>>>>>>> That's what I've found too.
>>>>>>>>> 
>>>>>>>>>> The proposed solution is to try 'jcmd -l' several times, with a short
>>>>>>>>>> sleep in between.
>>>>>>>>> Thread.sleep() isn't great, but I'm not sure there is an alternative.
>>>>>>>>> 
>>>>>>>>>> Also I have commented out the testCase02() due to another bug:
>>>>>>>>>> "JDK-8228850: jhsdb jinfo fails with ClassCastException:
>>>>>>>>>> s.j.h.oops.TypeArray cannot be cast to s.j.h.oops.Instance",
>>>>>>>>>> which is not a test bug. IMO, it is better to run the test and skip a
>>>>>>>>>> sub-case than to skip the entire test.
>>>>>>>>>> 
>>>>>>>>>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8228960
>>>>>>>>>>     Webrev: http://cr.openjdk.java.net/~mseledtsov/8228960.00/
>>>>>>>>> Looks OK to me.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Severin
>>>>>>>>>