Setting up and checking your Linux environment
Linux® operating systems undergo a large number of patches and updates.
IBM® personnel cannot test the Java VM 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. To obtain the latest refreshes and view the fixes lists, see the Java SDK support pages.
Working directory
The current working directory of the Java VM process is the default location for the generation of core files, Java™ dumps, heap dumps, and the Java VM trace outputs, including Application Trace and Method trace. Enough free disk space must be available for this directory. Also, the Java VM must have write permission.
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 Configuring your system in the OpenJ9 user documentation.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:
Review the configuration of these tools or consider disabling the tools if problems occur when you attempt to generate system dumps from the Java VM.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>
- Java Virtual Machine settings
-
To generate core files when a crash occurs, check that the Java VM is set to do so.
Run java -Xdump:what, which should produce the following output:
These values are the default settings. At least-Xdump:system: events=gpf+abort+traceassert+corruptcache, label=/mysdk/sdk//jrebin/core.%Y%m%d.%H%M%S.%pid.dmp, range=1..0, priority=999, request=serial
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 thelabel
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.-Xdump:system:label=/mysdk/sdk/jre/bin/core.%Y%m%d.%H%M%S.%pid.dmp
ZipException or IOException on Linux
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
Linux on zSeries
If you are running Java 7 on zLinux under zVM on z10 hardware, you must use zVM Version 5 Release 2 or later. If you use previous versions of zVM, you do not get the performance benefits available with DFP.Threading libraries
The distributions supported by the IBM Java VM provide the enhanced Native POSIX Threads Library for Linux (NPTL).
You can discover your glibc version by changing to the /lib directory and running the file libc.so.6. 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_setup__linux_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.