IBM User Guide for Java V7 on Windows > Troubleshooting and support > Problem determination

Attach API problem determination

This section helps you solve problems involving the Attach API.

The IBM Java™ Attach API uses shared semaphores, sockets, and file system artifacts to implement the attach protocol. Problems with these artifacts might adversely affect the operation of applications when they use the attach API.

Note: Error messages from agents on the target VM go to stderr or stdout for the target VM. They are not reported in the messages output by the attaching VM.

Deleting or changing permissions on directories and files in /tmp

The attach API depends on the contents of a common directory. By default the common directory is /tmp/.com_ibm_tools_attach. The common directory must have owner, group, and world read, write, and execute permissions, and the sticky bit must be set. The common files _attachlock, _master, and _notifier must have owner, group, and world read and write permissions. Execute permissions are not required.

Problems are caused if you modify the common directory in one of the following ways:

• Deleting the common directory.
• Deleting the contents of the common directory.
• Changing the permissions of the common directory or any of its content.

If you do modify the common directory, possible effects include:

• Semaphore "leaks" might occur, where excessive numbers of unused shared semaphores are opened. You can remove the semaphores using the command:

  ipcrm -s <semid>

  Use the command to delete semaphores that have keys starting with "0xa1".
• The Java VMs might not be able to list existing target VMs.
• The Java VMs might not be able to attach to existing target VMs.
• The Java VM might not be able to enable its attach API.
• Java processes might not terminate, or might take an excessive length of time to terminate.

If the common directory cannot be used, a Java VM attempts to re-create the common directory. However, the JVM cannot re-create the files related to currently executing VMs.

The VirtualMachine.attach(String id) method reports AttachNotSupportedException: No provider for virtual machine id

There are several possible reasons for this message:

• The target VM might be owned by another userid. The attach API can only connect a VM to a target VM with the same userid.
• The attach API for the target VM might not have launched yet. There is a short delay from when the Java VM launches to when the attach API is functional.
• The attach API for the target VM might have failed. Verify that the directory /tmp/.com_ibm_tools_attach/<id> exists, and that the directory is readable and writable by the userid.
• The target directory /tmp/.com_ibm_tools_attach/<id> might have been deleted.
• The attach API might not have been able to open the shared semaphore. To verify that there is at least one shared semaphore, use the command:

  ipcs -s

  If there is a shared semaphore, at least one key starting with "0xa1" appears in the output from the ipcs command.

  Note: The number of available semaphores is limited on systems which use System V IPC, including Linux, z/OS, and AIX.

The VirtualMachine.attach() method reports AttachNotSupportedException

There are several possible reasons for this message:

• The target process is dead or suspended.
• The target process, or the hosting system is heavily loaded. The result is a delay in responding to the attach request.
• The network protocol has imposed a wait time on the port used to attach to the target. The wait time might occur after heavy use of the attach API, or other protocols which use sockets. To check if any ports are in the TIME_WAIT state, use the command:

  netstat -a

The VirtualMachine.loadAgent(), VirtualMachine.loadAgentLibrary(),, or VirtualMachine.loadAgentPath() methods report com.sun.tools.attach.AgentLoadException or com.sun.tools.attach.AgentInitializationException

There are several possible reasons for this message:

• The JVMTI agent or the agent JAR file might be corrupted. Try loading the agent at startup time using the -javaagent, -agentlib, or -agentpath option, depending on which method reported the problem.
• The agent might be attempting an operation which is not available after VM startup.

A process running as root can see a target using AttachProvider.listVirtualMachines(), but attempting to attach results in an AttachNotSupportedException

A process can attach only to processes owned by the same user. To attach to a non-root process from a root process, first use the su command to change the effective UID of the attaching process to the UID of the target UID, before attempting to attach.

The /tmp/.com_ibm_tools_attach directory contains many directories with numeric file names

Each Java process creates a private directory in the /tmp/.com_ibm_tools_attach directory, using its process ID as the directory name. When the process exits, it deletes this private directory. If the process, or the operating system, crashes, or you end the process by using the SIGKILL command, these obsolete directories are not removed.

Subsequent Java processes delete obsolete directories automatically over time. Each process examines a sample of the directories in /tmp/.com_ibm_tools_attach. If a directory is obsolete and is owned by the user that is running the process, the process deletes that directory.

To force deletion of all obsolete directories that are owned by the current user, run the jconsole command, found in the SDK bin directory. When the New Connection dialog is displayed, click Cancel, then exit the application.

To clean up all obsolete directories for all users, run the jconsole command as the

root user.

Parent: Problem determination

Error 404 - Not Found

The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.