JDK-7160774 : jinfo, jmap, jstack man pages should document ptrace restrictions in recent Ubuntu versions
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 8,9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2012-04-11
  • Updated: 2023-12-14
  • Resolved: 2016-12-14
Related Reports
Relates :  
JDK-8059035 - Break the (implicit) dependency from jdk.jcmd to jdk.hotspot.agent
Relates :  
JDK-7050524 - SA, jinfo, jmap, jstack don't work on Ubuntu > 10.10: DebuggerException: Can't attach to the process
Description
Certain Linux distributions (specifically Ubuntu 10.10 and later, and possibly others) have placed restrictions on the ptrace(2) system call that cause jinfo, jmap, and jstack (and the Serviceability Agent) not to work. See 7050524. This is also documented in the JDK 7 release notes [1].

There is probably nothing that can be done in the tools themselves to fix or to work around this problem. Working around the problem requires a system administrator to change the system configuration.

The jinfo, jmap, and jstack man pages for Linux should have some information about this limitation. At the very least they should refer to the PTRACE_ATTACH section of the ptrace(2) man page [2]. Perhaps the man pages should also include information about the workaround. See the workaround section of 7050524 for specific details. (However, employing this workaround makes the system less secure, so it may be unwise to encourage people to do this.)

I'm not sure which distros this applies to. So far Ubuntu 10.10 and later are the only ones I've confirmed. The ptrace restriction facility has been checked into Fedora 17 but is disabled by default [3]. However, it may be enabled in the future, which will introduce the same issues as in Ubuntu.

There may be other areas of the system (such as the Serviceability Agent) that are impacted by the ptrace restrictions. We should consider updating the documentation for them as well.

[1] http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html

[2] http://manpages.ubuntu.com/manpages/precise/man2/ptrace.2.html

[3] https://lists.fedoraproject.org/pipermail/devel/2012-April/165745.html
Comments
I don't think we should be closing bugs that currently are not high enough priority to fix. Especially when a plan to address them sort-of exists.
14-12-2016
This is not on our list of current priorities. If this changes, please reopen this issue.
14-12-2016
> Can we rejigger things so that the various j commands use the mechanism that works, whenever possible? Yes. This is under way. A lot of the sub-commands to jmap, jstack and jinfo has been ported to use the attach mechanism instead of SA. When all sub-commands are ported, we will remove the SA functionality from jmap, jstack and jinfo. Instead we will introduce a separate tool to launch the SA commands. See JDK-8059035 and bugs linked from that one.
04-06-2015
If the ptrace attach fails with EPERM, we can provide more details in the exception message than simply Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process We could even inspect the value of ptrace_scope if yama is turned on and give users instructions
03-06-2015
I notice that, with the ptrace restrictions on, the commands jstack $PID jinfo $PID succeed, whereas jmap $PID jstack -m $PID fail. The sources contain wording like this: * This class is the main class for the JStack utility. It parses its arguments * and decides if the command should be executed by the SA JStack tool or by * obtained the thread dump from a target process using the VM attach mechanism which suggests that the "VM attach mechanism" (whatever that is) does *not* use ptrace and the SA mechanism does. Can we rejigger things so that the various j commands use the mechanism that works, whenever possible?
03-06-2015