You could try creating a symbolic link to another directory of your choice. We do that for data storage directory, don't see why it wouldn't work for the dump directory.
Not sure if that is set in a config file somewhere.
According to what our dev says, it is not
possible. However, together with the AMD HS (12.4.5), the core files will be saved in the
“var” directory (partition) and, as a result, this will allow to keep the “usr” partition
smaller - just big enough for program and configuration files.
Speaking as a Linux admin
The default location for a core dump is the current working directory of the running binary at the time of the crash, so it would be *hypothetically* possible to add code to the AMD's binaries to change to a different working directory after binary launch to have some control over where the core drops, but a change like this is generally discouraged in practice because it tends to add numerous additional variables to be take into account in other places in the coding. Having seen past examples in other projects where this was tried and the problems they encountered, I strongly recommend against this approach.
The location of core dumps is also configurable at the Linux system level. Modifying the parameter "kernel.core_pattern" in the file /etc/sysctl.conf will change the default core location (and naming pattern) system wide. This is the recommended approach for changing where core dumps are stored should that be required.
A couple samples for reference:
will drop all cores to the /var/core/ directory, naming them core.binary_name.process_ID
will drop all cores to the /nas/cores/ directory, naming them host_name.binary_name.core.epoch_timestamp.process_ID
The second would be most useful when multiple hosts share a network location for core dumps.
More complete details on this setting are available at
It is not that it is no longer relevant in RHEL7; it is that in an RHEL7 default install, systemd (introduced to RHEL in v7 and not optional) hijacks the standard core dumping process. However, according to my tests, if RHEL7 is installing using the Dynatrace provided kickstart script, the kickstart script configures systemd not to interfere and these changes do work as expected.
Using the Dynatrace provided kickstart script is the recommended and officially supported method of installing the RHEL7 OS for the AMD appliance.