> On Aug 13, 2019, at 2:57 PM, mikhailo.seledt...@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.vande...@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.seledt...@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.seledt...@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<sgehw...@redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Misha,
>>>>>>>>>
>>>>>>>>> On Tue, 2019-08-06 at 20:17 -0700, mikhailo.seledt...@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
>>>>>>>>>
