Setting up and checking your Linux environment

Linux operating systems undergo a large number of patches and updates.

IBM® personnel cannot test the JVM against every patch. The intention is to test against the most recent releases of a few distributions. In general, you should keep systems up-to-date with the latest patches. See for an up-to-date list of releases and distributions that have been successfully tested against.

Working directory

The current working directory of the JVM process is the default location for the generation of core files, Java™ dumps, heap dumps, and the JVM trace outputs, including Application Trace and Method trace. Enough free disk space must be available for this directory. Also, the JVM must have write permission.

Linux system dumps (core files)

When a crash occurs, the most important diagnostic data to obtain is the system dump. To ensure that this file is generated, you must check the following settings.

Operating system settings

Operating system settings must be correct. These settings can vary by distribution and Linux version.

To obtain full core files, set the following ulimit options:
ulimit -c unlimited		 turn on corefiles with unlimited size  
ulimit -n unlimited		 allows an unlimited number of open file descriptors
ulimit -m unlimited		 sets the user memory limit to unlimited
ulimit -f unlimited		 sets the file size to unlimited

For more information about ulimit settings, see System resource limits and the ulimit command.

From Java 5, the ulimit -c value for the soft limit is ignored and the hard limit value is used to help ensure generation of the core file.

Linux tools such as the Automatic Bug Reporting Tool (ABRT) and Apport tool use settings in the Linux /proc/sys/kernel/core_pattern file to redirect core files to a diagnostic program. These tools and the /proc/sys/kernel/core_pattern file settings they use might prevent the JVM from successfully producing system dumps. The tools are enabled by default in some Linux distributions. You might see this error message:
JVMPORT030W "proc/sys/kernel/core_pattern setting ..... 
specifies that the core dump is to be piped to an external program.
Attempting to rename either core or core.<pid>
Review the configuration of these tools or consider disabling the tools if problems occur when you attempt to generate system dumps from the JVM.
Java Virtual Machine settings

To generate core files when a crash occurs, check that the JVM is set to do so.

Run java -Xdump:what, which should produce the following output:
These values are the default settings. At least events=gpf must be set to generate a core file when a crash occurs. You can change and set options with the command-line option -Xdump:system[:name1=value1,name2=value2 ...]
Available disk space

The available disk space must be large enough for the core file to be written.

The JVM allows the core file to be written to any directory that is specified in the label option. For example:
To write the core file to this location, disk space must be sufficient (up to 4 GB might be required for a 32-bit process), and the correct permissions for the Java process to write to that location.

ZipException or IOException on Linux

When using a large number of file descriptors to load different instances of classes, you might see an error message " error in opening .zip file", or some other form of IOException advising that a file could not be opened. The solution is to increase the provision for file descriptors, using the ulimit command. To find the current limit for open files, use the command:
ulimit -a
To allow more open files, use the command:
ulimit -n 8196

Threading libraries

The distributions supported by the IBM JVM provide the enhanced Native POSIX Threads Library for Linux (NPTL).

For information on the threading libraries that are supported by the IBM Virtual Machine for Java on specific Linux platforms, see

You can discover your glibc version by changing to the /lib directory and running the file The Linux command ldd prints information that should help you to work out the shared library dependencies of your application.

Using CPU Time limits to control runaway tasks

Because real time threads run at high priorities and with FIFO scheduling, failing applications (typically with tight CPU-bound loops) can cause a system to become unresponsive. In a development environment it can be useful to ensure runaway tasks are killed by limiting the amount of CPU that tasks might consume. See Linux system dumps (core files) for a discussion on soft and hard limit settings.

The command ulimit -t lists the current timeout value in CPU seconds. This value can be reduced with either soft, for example, ulimit -St 900 to set the soft timeout to 15 minutes or hard values to stop runaway tasks.