glibc 2.44 puts tunable defaults in the loader cache

The glibc 2.44 release announcement, published on July 25, adds system-wide tunables through /etc/tunables.conf and ldconfig. Administrators can use the file to configure runtime library behavior across programs. At startup, the loader cache supplies the resulting settings, so the mechanism has a defined application point at program startup. Editing the text file alone is not the complete configuration operation.

I have worked with C for thirty years and still see its interoperability role as a major reason to understand the runtime library. A setting outside an application can affect the library behavior that application receives. I want such settings to have documented precedence and a way to describe their effective scope. This release supplies those details, together with an explicit warning that tunable names and their configuration mechanism are not stable library interfaces.

ldconfig compiles the configuration into the cache

The system-wide tunables documentation specifies one setting per line. ldconfig reads the file and writes the settings as an extension in /etc/ld.so.cache. Programs read the cached settings when they start. Programs already running do not receive an update from changing the cache.

For illustration, a configuration file can contain a single documented malloc setting.

glibc.malloc.trim_threshold=128

This is a syntax example, not a recommendation for a workload. The value comes from the manual example, and the appropriate setting needs an application-specific reason. I would record that reason alongside the deployment configuration before applying a library policy to multiple programs. A syntactically valid value does not establish that the value improves their behavior.

The startup boundary affects how an operator verifies a change. Looking only at a running process after rebuilding the cache cannot show that it consumed the new setting. I would start a fresh instance under the intended configuration and check the behavior that motivated the change. The existing process and the new process can legitimately have different startup defaults during a staged rollout.

The file also supports the include syntax used by ld.so.conf. Included configuration therefore needs to be considered when reviewing the effective settings. I would keep the set of included files in the configuration inventory, since the top-level file may not contain the whole policy. Reproducing a setting on another machine requires the inputs that ldconfig actually read.

Defaults can permit or prevent environment overrides

By default, a system-wide value overrides the built-in default but remains overridable through GLIBC_TUNABLES. The general tunables chapter describes that environment variable as colon-separated name-value pairs. The system-wide file provides another source for the same class of settings, with its own precedence controls.

A nonoverridable prefix, or its short spelling -, prevents the environment from overriding a setting. The overridable prefix, also written +, restores the default override behavior. This makes the administrator decision explicit. A configuration can set a common default while allowing an individual application to choose differently, or it can impose the setting through the global mechanism.

I would distinguish those two policies in a change review. An overridable default gives application configuration a documented route to an exception. A non-overridable value removes that route for the affected setting. The operational justification should explain why the wider policy is appropriate, especially when several unrelated programs consume the same runtime library.

The documentation includes program filters for exceptions. A filter has the form [proc:pattern], followed by settings that apply when it matches. The pattern can be a fully qualified executable path or its basename. Filter effects last until the next filter, an empty [] filter, or the relevant end of file. An exception therefore depends on placement as well as its individual setting.

The process name comes from /proc/self/exe when available, or from argv[0] outside secure execution. I would use the documented name source when verifying a filter. An exception written against a name that the filter does not see would leave the program with the broader default, even though the configuration looked plausible during review.

Secure execution has a distinct policy

The default system-wide behavior applies settings only to processes outside AT_SECURE. The manual offers onlysecure, nonsecure and anysecure prefixes to select the intended process class. Secure execution includes cases such as setuid or setgid binaries and elevated capabilities. Applying a setting to ordinary programs does not automatically apply it to those programs.

The environment variable is ignored entirely for AT_SECURE processes. Consequently, the system-wide file is the documented way to supply a tunable for that class. glibc warns that settings applied through this file do not undergo per-tunable security screening. It requires administrator-only write access and treats the file as trusted to the same degree as the loader cache.

I would keep the secure-execution choice visible in any proposed configuration. The distinction changes which programs receive the policy and whether an environment override exists at all. Testing an ordinary shell invocation would not establish behavior for a secure-execution invocation. The verification case needs to match the process class the configuration intends to affect.

The release preserves explicit limits on compatibility

The announcement also imports more optimized, correctly rounded CORE-MATH routines, including cosh, sinh and tanh. Those are separate runtime changes from the new configuration path. I would assess numerical behavior and tunable policy independently, since they require different evidence and have different reasons for adoption.

Both the announcement and manual warn that specific tunables and the file format and path may change across releases. The general chapter also says distributions can supply different sets of tunables. A configuration-management rule should therefore identify the library and distribution it targets. Treating this file as a permanent cross-platform configuration contract would exceed the compatibility the project documents.

For a rollout, I would retain the exact input files, the cache regeneration step and the fresh-process verification case together. That record explains how the text becomes runtime defaults and which programs should consume them. It also gives a subsequent upgrade review enough information to check that the intended setting still exists and that its override and secure-execution rules remain appropriate.