<div dir="ltr">I recreated this problem in RedHat 6.4 installed in a virtual machine where I login as the same user on tty1 and tty2 - the setup for tmp is the same. I also tried with VM running Fedora 19 with 2 terminal windows in the X session. I tried to read files from /tmp/hsperfdata_$username/* from the terminal where I run jstack and I was able to read files (named after java processes pids).<div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 2:42 PM, Staffan Larsen <span dir="ltr"><<a href="mailto:staffan.larsen@oracle.com" target="_blank">staffan.larsen@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It could also be that one of the processes do not have access to /tmp (or that it is mapped differently).<br>
<span class="HOEnZb"><font color="#888888"><br>
/Staffan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 21 nov 2013, at 14:14, Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br>
<br>
> On 21/11/2013 13:06, Piotr Bzdyl wrote:<br>
>> Hello,<br>
>><br>
>> I wasn't sure which OpenJDK mailing list I should choose for my question. As I have issues with jstack SA related group seemed the best place.<br>
>><br>
>> I have the following issue:<br>
>><br>
>> On console one (let's call it pts/1) I start a sample java app (let's say its pid is 1234). On another console (pts/2) I execute:<br>
>><br>
>> jstack 1234<br>
>><br>
>> As a result pts/2 displays:<br>
>> 1234: Unable to open socket file: target process not responding or HotSpot VM not loaded<br>
>> The -F option can be used when the target process is not responding<br>
>><br>
>> And on pts/1 I see the thread dump printed. I would rather expect that the thread dump will be displayed on pts/2 and nothing will be printed to pts/1. I tried to use different versions of OpenJDK but the result was always the same.<br>
>><br>
>> Could you provide me any hints what might be wrong?<br>
>><br>
>> Best regards,<br>
>> Piotr<br>
> Are pts/1 and pts/2 the same user? Alternatively, any special options to the target VM that disables the attach mechanism?<br>
><br>
> In any case, I suspect the reason that pts/1 is print the stack trace is that the mechanism to start the attach mechanism in the target VM requires signalling the target VM with SIGQUIT, the same signal that is used to get a VM to do a thread dump to its own stdout.<br>
><br>
> -Alan<br>
<br>
</div></div></blockquote></div><br></div>