DAG

Shortcuts:
Dconf ∑ Dstat ∑ Dwall ∑ Dweb ∑ Dwscan ∑ Lyrics ∑ mrepo ∑ Pixies.. ∑ RPMs ∑ unoconv ∑ wascii ∑ wiipresent ∑ Yam ∑

Google Site Search:
Flemish symbol European symbol
» Dag Wieers » Howtos » Red Hat and Fedora Core compatibility tweaks 
Red Hat and Fedora Core compatibility tweaks
Although Red Hat integrates new and improved technologies into their kernels that may break older programs, they allow tweaks to restore the older behaviour of kernels. This document will explain some of these tweaks that are sometimes necessary for running older, legacy (mostly proprietary and binary) applications.

In most, if not all, cases that you rely on these tweaks, the program is at fault and should be fixed.
Software known to have problems with some of these newer technologies include, but is not limited to: Adobe Acrobat Reader, Lotus Domino, DB2, Tivoli, TSM, Sun Java and IBM Java. Newer versions may already have been fixed. Sometimes it's only the supplied Java-based installer that needs tweaking, not the program itself.

Some of this is documented in the release notes of Red Hat Enterprise Linux and Fedora Core, still a lot of people seem to be unaware of the consequences and remedies, and make the understandable mistake of blaming the operating system's stability for this. It would be interesting to keep a list around of known applications that break. If you encounter such breakage and were able to fix it, please send me the name of the program and the behaviour noticed. Please include copy&paste of the breakage so that we can include that too. (Nice for people using Google) In most of the cases you won't. The resulting behaviour could be a segmentation fault on start-up, random crashes or even unexpected behaviours and spurious messages. For normal system administrators it's very hard to pinpoint the cause to one of these tweaks, except if you try one at a time or use a combination of them and see if the situation improves.

I do not advice you to enable all tweaks by default, nor do I guarantee a solution by using any or all of these tweaks. But if you succeed in fixing a situation where you otherwise would have continuous problems running software, do tell me about it !
Applies to RHEL3+ and Fedora Core.

Native POSIX Thread Library (NPTL), a new implementation of POSIX threads for Linux, provides performance improvements and increased scalability.

This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed.

To disable NPTL and enable the older LinuxThreads behaviour one time on a per process basis, you can prefix the command by the following environment variable:
LD_ASSUME_KERNEL=2.4.19 cmd
or to use LinuxThreads without floating stacks (older):
LD_ASSUME_KERNEL=2.2.5 cmd
You can also disable it permanently system-wide, by adding the following to /etc/initscript and then reboot your system.
export LD_ASSUME_KERNEL=2.4.19
To verify that it works, you can use the following command:
getconf GNU_LIBPTHREAD_VERSION
See also http://en.wikipedia.org/wiki/NPTL or initscript(5) Applies to RHEL3+ and Fedora Core.

UTF-8 (8-bit Unicode Transformation Format) is a lossless, variable-length character encoding for Unicode. It uses groups of bytes to represent the Unicode standard for the alphabets of many of the world's languages.

Some applications have problems using UTF-8 or parsing the LANG environment variable with UTF-8 specified.

You can fix this one time on a per process basis by prefixing the command with the LANG environment variable, like:
LANG="C" cmd
Or you can disable UTF-8 permanently system-wide, by changing the following in /etc/sysconfig/i18n and then rebooting your system:
LANG="C"
See also http://en.wikipedia.org/wiki/UTF-8 Applies to RHEL3+ and Fedora Core.

Some applications (such as older versions of Java) are written to assume a 3GB virtual address space; when run on systems with larger virtual address spaces (such as 64-bit x86-64 systems, or 32-bit systems running the hugemem kernel) such applications can malfunction.

The setarch utility makes it possible to emulate a 3GB virtual address space, allowing such applications to run properly:
setarch -3 cmd
Applies to RHEL3 U3+ and Fedora Core.

Exec-Shield is a security-enhancing modification to the Linux kernel that makes large parts of specially-marked programs -- including their stack -- not executable. This can reduce the potential damage of some security holes, such as buffer overflow exploits.

Normally Exec-shield is by default only enabled for binaries that are marked as such (set to 1). You can test this using the execstack command on an ELF binary.
execstack -q binary
For this reason there should be no imminent reason to disable Exec-shield. But you may want to disable Exec-shield's randomizing VM mapping behaviour. (See next)
You can disable it one time per process, by prefixing the command by setarch, like:
setarch i386 cmd
To disable it permanently system-wide, you have 2 options. Either add to /etc/sysctl.conf:
kernel.exec-shield = 0
And make it effective by running:
sysctl -w kernel.exec-shield=0
Or you can also disable it permanently by appending the following to the kernel command line in your bootloader (lilo or grub) and rebooting afterwards.
exec-shield=0
Also look at setarch(8) and execstack(8) utilities and see http://en.wikipedia.org/wiki/Exec_Shield Applies to RHEL3 U3+ and Fedora Core.

Exec-shield randomizes VM mappings, this may confuse programs that do not expect this behaviour (and for that reason alone are considered broken).

To disable it permanently system-wide, add the following to /etc/sysctl.conf:
kernel.exec-shield-randomize = 0
And make it effective by running:
sysctl -w kernel.exec-shield-randomize=0
Applies to RHEL4 and Fedora Core 3+.

In addition to Exec-shield, newer kernels also require support for the legacy virtual addresses layout to be enabled. This may be your first hint to try prior to disabling Exec-shield altogether.

You can enable it one time per process, by prefixing the command by setarch, like:
setarch i386 -L cmd
To disable it permanently system-wide, add the following to to /etc/sysctl.conf:
vm.legacy_va_layout = 1
And to make it effective, run:
sysctl -w vm.legacy_va_layout=1
Applies to RHEL3 U4+ and Fedora Core.

To disable prelinking permanently system-wide, add the following to /etc/sysconfig/prelink:
PRELINKING=no
then execute the following command to make it effective:
prelink -ua
Also see prelink(8) Applies to RHEL4 and Fedora Core 2+.

Virtual Dynamic Shared Object support enables usage of sysenter instruction to enter the kernel instead of using int 80h instructions. Sysenter is faster if the cpu supports it (quite dramatically so on newer CPUs like P4s).

To disable it permanently system-wide, you have 2 options. Either add to /etc/sysctl.conf:
kernel.vdso = 0
And to make it effective, run:
sysctl -w kernel.vdso=0
Or you can also disable it permanently by appending the following to the kernel command line in your bootloader (lilo or grub) and rebooting afterwards.
vdso=0
Applies to RHEL4 and Fedora Core 2+.

SELinux is an enhancement to the Linux kernel that implements discretionary access control (DAC) and role-based access control (RBAC).

Disable SELinux by changing the following in /etc/sysconfig/selinux and rebooting the system.
SELINUX=disabled
See also http://fedora.redhat.com/docs/selinux-faq/ Applies to RHEL4 and Fedora Core 3+.

Newer versions of glibc perform additional internal sanity checks to prevent and detect data corruption as early as possible. By default, should corruption be detected, a message similar to the following will be displayed on standard error (or logged via syslog if stderr is not open):
*** glibc detected *** double free or corruption: 0x0937d008 ***
By default, the program that generated this error will also be killed; however, this (and whether or not an error message is generated) can be controlled via the MALLOC_CHECK_ environment variable. You can disable these internal sanity checks one time per process by doing:
MALLOC_CHECK_=0 cmd
If MALLOC_CHECK_ is explicitly set a value other than 0, this causes glibc to perform more tests that are more extensive than the default, and may impact performance.

Should you have a program from a third party ISV that triggers these corruption checks and displays a message, you should file a defect report with the application's vendor, since this indicates a serious bug. Look into the following items: Pasi Pirhonen, for proof-reading and general advice.