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.

The Java™ service team has a tool named ReportEnv that plugs into your JVM and reports on the JVM environment in real time. Your JVM environment affects the operation of the JVM. ReportEnv reports on environment variables and command-line parameters. It is a GUI tool, although it can be run without a GUI. The GUI allows you to browse your environment and, to some extent, dynamically change it. The tool also has a mechanism to generate reports to tell you the exact state of your JVM environment. The ReportEnv tool is available on request from jvmcookbook@uk.ibm.com.

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
The current ulimit settings can be displayed using:
ulimit -a

These values are the "soft" limit, and are set for each user. These values cannot exceed the "hard" limit value. To display and change the "hard" limits, the same ulimit commands can be run using the additional -H flag. 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. You can disable core file generation by using the -Xdump:system:none command-line option.

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:
-Xdump:system:
    events=gpf+abort,
    label=/mysdk/sdk/jre/bin/core.%Y%m%d.%H%M%S.%pid.dmp,
    range=1..0,
    priority=999,
    request=serial
The values above 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:
-Xdump:system:label=/mysdk/sdk/jre/bin/core.%Y%m%d.%H%M%S.%pid.dmp
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 "java.util.zip.ZipException: 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

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.



© Copyright IBM Corporation 2005, 2010. All Rights Reserved.
© Copyright Sun Microsystems, Inc. 1997, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 USA. All rights reserved.
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
This information center is powered by Eclipse technology. (http://www.eclipse.org/)