[PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[DJ Delorie]

---
 man/man5/tunables.conf.5 | 145 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 145 insertions(+)
 create mode 100644 man/man5/tunables.conf.5

diff --git a/man/man5/tunables.conf.5 b/man/man5/tunables.conf.5
new file mode 100644
index 000000000..29beeb8f8
--- /dev/null
+++ b/man/man5/tunables.conf.5
@@ -0,0 +1,145 @@
+.TH tunables.conf 5 (date) "Linux man-pages (unreleased)"
+.SH NAME
+tunables.conf \- tunables configuration file
+.SH SYNOPSIS
+.nf
+.B /etc/tunables.conf
+.fi
+.SH DESCRIPTION
+Tunables are a feature in the GNU C Library
+that allows application authors and distribution maintainers
+to alter the runtime library behavior to match their workload.
+For a list of supported tunables,
+please consult the glibc manual
+that corresponds to your installed version of glibc,
+or run the following command:
+.P
+.in +4n
+.EX
+ld.so \-\-list\-tunables
+.EE
+.P
+The file is parsed by
+.BR \%ldconfig (8)
+and the results stored in
+.IR /etc/ld.so.cache .
+The resulting data is read when a new process is created by
+.IR ld.so .
+.P
+Each line in the file
+.I /etc/tunables.conf
+specifies a tunable,
+which is specified with a string of the form
+.IB name = value \f[R].\f[]
+.P
+The syntax allows lines to start with the keyword
+.I include
+followed by a
+.BR \%glob (7)
+pattern.
+Files matching that pattern will be processed
+as if their contents were included at that point.
+.P
+Each line may include zero or more keywords or symbols at the beginning,
+which affect how each tunable affects each processes.
+The keywords must be separated by whitespace,
+but the symbols need not be.
+.TP
+.B overridable
+.TQ
+.B +
+Allow the tunable to be overridden by the
+.B GLIBC_TUNABLES
+environment variable when the process runs
+(this is the default).
+.TP
+.B nonoverridable
+.TQ
+.B \-
+Do not allow the tunable to be overridden by the environment variable.
+.TP
+.B onlysecure
+.TQ
+.B @
+The tunable applies only to
+.B AT_SECURE
+processes,
+such as one started from a set-user-ID program,
+or one with elevated capabilities.
+.TP
+.B nonsecure
+.TQ
+.B $
+The tunable applies only to
+.RB non- AT_SECURE
+processes (this is the default).
+.TP
+.B anysecure
+.TQ
+.B *
+The tunable applies to both
+.B AT_SECURE
+and
+.RB non- AT_SECURE
+processes.
+.P
+The file may also contain
+.IR filters ,
+which limit the tunables following it.
+The effects of a filter are terminated by
+any of the following:
+.IP \[bu] 3
+The end of the file.
+.PD 0
+.IP \[bu]
+The end of an included file.
+.IP \[bu]
+An
+.B include
+directive.
+.IP \[bu]
+A new (possibly empty) filter.
+.PD
+.P
+The syntax is:
+.P
+.in +4n
+.EX
+.BI [ filter : pattern ]
+.EE
+.in
+.TP
+.B proc
+The
+.B proc
+filter limits the following tunables to processes
+whose name matches the pattern.
+The pattern may be an absolute path
+or just the base name.
+.P
+A filter can also be empty:
+.BR [] .
+Such a filter has no effects.
+.SH FILES
+.TP
+.I /etc/tunables.conf
+.TP
+.I /etc/ld.so.cache
+cached copy of tunables
+.SH EXAMPLES
+Example configuration file:
+.P
+.in +4n
+.EX
+glibc.malloc.arenas_max=5
+onlysecure glibc.malloc.arenas_max=1
+\-glibc.pthread.rseq=1
+[proc:/bin/bad.program]
+\-glibc.pthread.rseq=0
+[proc:some.program]
+\-glibc.malloc.mmap_threshold=65536
+.EE
+.in
+.SH SEE ALSO
+.BR ld.so (8),
+.BR ldconfig (8)
-- 
2.47.3

Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 4944 bytes --]

Hi DJ,

> Date: 2026-08-06 16:44:30-0400
> From: DJ Delorie <dj@redhat.com>
>
> 
> ---

You forgot to sign.

>  man/man5/tunables.conf.5 | 145 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 145 insertions(+)
>  create mode 100644 man/man5/tunables.conf.5
> 
> diff --git a/man/man5/tunables.conf.5 b/man/man5/tunables.conf.5
> new file mode 100644
> index 000000000..29beeb8f8
> --- /dev/null
> +++ b/man/man5/tunables.conf.5
> @@ -0,0 +1,145 @@
> +.TH tunables.conf 5 (date) "Linux man-pages (unreleased)"
> +.SH NAME
> +tunables.conf \- tunables configuration file
> +.SH SYNOPSIS
> +.nf
> +.B /etc/tunables.conf
> +.fi
> +.SH DESCRIPTION
> +Tunables are a feature in the GNU C Library
> +that allows application authors and distribution maintainers
> +to alter the runtime library behavior to match their workload.
> +For a list of supported tunables,
> +please consult the glibc manual
> +that corresponds to your installed version of glibc,
> +or run the following command:
> +.P
> +.in +4n
> +.EX
> +ld.so \-\-list\-tunables
> +.EE
> +.P
> +The file is parsed by
> +.BR \%ldconfig (8)
> +and the results stored in
> +.IR /etc/ld.so.cache .
> +The resulting data is read when a new process is created by
> +.IR ld.so .

Sorry for noticing this in v4; I forgot about it.  I see this unresolved
issue from earlier versions remains.

ld.so(8) runs when a new program is executed --execve(2)--, not when
a new process is created --fork(2)--, AFAIK.

	alx@devuan:~$ MANWIDTH=64 man fork | grep ld.so
	alx@devuan:~$ MANWIDTH=64 man execve | grep -C2 ld.so
	     If the executable is an a.out  dynamically  linked  binary
	     executable  containing shared‐library stubs, the Linux dy‐
	     namic linker ld.so(8) is called at the start of  execution
	     to  bring  needed  shared objects into memory and link the
	     executable with them.
	--
	     ptrace(2), exec(3), fexecve(3),  getauxval(3),  getopt(3),
	     system(3),  capabilities(7),  credentials(7),  environ(7),
	     path_resolution(7), ld.so(8)

	Linux man‐pages 6.18‐18... 2026‐02‐08                 execve(2)

> +.P
> +Each line in the file
> +.I /etc/tunables.conf
> +specifies a tunable,
> +which is specified with a string of the form
> +.IB name = value \f[R].\f[]
> +.P
> +The syntax allows lines to start with the keyword
> +.I include

s/I/B/  (since it's a literal, not a variable)


Have a lovely night!
Alex

> +followed by a
> +.BR \%glob (7)
> +pattern.
> +Files matching that pattern will be processed
> +as if their contents were included at that point.
> +.P
> +Each line may include zero or more keywords or symbols at the beginning,
> +which affect how each tunable affects each processes.
> +The keywords must be separated by whitespace,
> +but the symbols need not be.
> +.TP
> +.B overridable
> +.TQ
> +.B +
> +Allow the tunable to be overridden by the
> +.B GLIBC_TUNABLES
> +environment variable when the process runs
> +(this is the default).
> +.TP
> +.B nonoverridable
> +.TQ
> +.B \-
> +Do not allow the tunable to be overridden by the environment variable.
> +.TP
> +.B onlysecure
> +.TQ
> +.B @
> +The tunable applies only to
> +.B AT_SECURE
> +processes,
> +such as one started from a set-user-ID program,
> +or one with elevated capabilities.
> +.TP
> +.B nonsecure
> +.TQ
> +.B $
> +The tunable applies only to
> +.RB non- AT_SECURE
> +processes (this is the default).
> +.TP
> +.B anysecure
> +.TQ
> +.B *
> +The tunable applies to both
> +.B AT_SECURE
> +and
> +.RB non- AT_SECURE
> +processes.
> +.P
> +The file may also contain
> +.IR filters ,
> +which limit the tunables following it.
> +The effects of a filter are terminated by
> +any of the following:
> +.IP \[bu] 3
> +The end of the file.
> +.PD 0
> +.IP \[bu]
> +The end of an included file.
> +.IP \[bu]
> +An
> +.B include
> +directive.
> +.IP \[bu]
> +A new (possibly empty) filter.
> +.PD
> +.P
> +The syntax is:
> +.P
> +.in +4n
> +.EX
> +.BI [ filter : pattern ]
> +.EE
> +.in
> +.TP
> +.B proc
> +The
> +.B proc
> +filter limits the following tunables to processes
> +whose name matches the pattern.
> +The pattern may be an absolute path
> +or just the base name.
> +.P
> +A filter can also be empty:
> +.BR [] .
> +Such a filter has no effects.
> +.SH FILES
> +.TP
> +.I /etc/tunables.conf
> +.TP
> +.I /etc/ld.so.cache
> +cached copy of tunables
> +.SH EXAMPLES
> +Example configuration file:
> +.P
> +.in +4n
> +.EX
> +glibc.malloc.arenas_max=5
> +onlysecure glibc.malloc.arenas_max=1
> +\-glibc.pthread.rseq=1
> +[proc:/bin/bad.program]
> +\-glibc.pthread.rseq=0
> +[proc:some.program]
> +\-glibc.malloc.mmap_threshold=65536
> +.EE
> +.in
> +.SH SEE ALSO
> +.BR ld.so (8),
> +.BR ldconfig (8)
> -- 
> 2.47.3

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[DJ Delorie]

Alejandro Colomar <alx@kernel.org> writes:
> You forgot to sign.

I will never remember that... :-P

>> +The resulting data is read when a new process is created by
>> +.IR ld.so .
>
> Sorry for noticing this in v4; I forgot about it.  I see this unresolved
> issue from earlier versions remains.

A program is a file on disk.  A process is a running memory image.

Neither fork() nor exec() cause the tunables to be loaded, the process
itself has to do that.  For dynamic ELF programs/processes built with
glibc, ld.so does it before it passes control to the ELF image.  There
are other types of programs/processes that do not use ld.so and thus do
not read the tunables cache (which is called "ld.so.cache" for a reason ;-)

I don't know how to say this clearly with fewer words...

>> +The syntax allows lines to start with the keyword
>> +.I include
>
> s/I/B/  (since it's a literal, not a variable)

Fixed.

Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

Hi DJ,

> Date: 2026-08-06 18:15:15-0400
> From: DJ Delorie <dj@redhat.com>
>
> Alejandro Colomar <alx@kernel.org> writes:
> > You forgot to sign.
> 
> I will never remember that... :-P
> 
> >> +The resulting data is read when a new process is created by
> >> +.IR ld.so .
> >
> > Sorry for noticing this in v4; I forgot about it.  I see this unresolved
> > issue from earlier versions remains.
> 
> A program is a file on disk.  A process is a running memory image.

Yup.  fork(3) creates a process (produces a new PID).  execve(2)
replaces the image of the current process with a program read from disk
(or in short, executes a program in the current process).

> 
> Neither fork() nor exec() cause the tunables to be loaded, the process
> itself has to do that.  For dynamic ELF programs/processes built with
> glibc, ld.so does it before it passes control to the ELF image.  There
> are other types of programs/processes that do not use ld.so and thus do
> not read the tunables cache (which is called "ld.so.cache" for a reason ;-)

Hmmmmm, let's say you call execve(2) several times without any fork(2)s.
Assuming a that the program paths that you pass to execve(2) are all
dynamic ELF programs built with glibc, I guess for every time you call
execve(2), ld.so(8) will be run, and the tunables stored in ld.so.cache
will be used.  Is this correct?

	#include <unistd.h>
	int
	main(int, char *argv[])
	{
		sleep(1);
		execve("proc/self/exe", argv, NULL);
	}

Let's also say you fork(2) several times, without any execve(2) calls.
I suppose that won't trigger any of this, right?

	#include <unistd.h>
	int
	main(void)
	{
		for (int i = 0; i < 10; i++) {
			sleep(1);
			fork();
		}
	}

From my understanding, only the first program will trigger this more
than once, right?

If so, I'd use the same wording that execve(2) uses:

	execve() executes the program referred to by path.

That is, execve(2) executes programs, and ld.so.cache is read when
a program is executed (in the current process).

> 
> I don't know how to say this clearly with fewer words...
> 
> >> +The syntax allows lines to start with the keyword
> >> +.I include
> >
> > s/I/B/  (since it's a literal, not a variable)
> 
> Fixed.
> 


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]

> Date: 2026-08-07 02:07:00+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> Hi DJ,
> 
> > Date: 2026-08-06 18:15:15-0400
> > From: DJ Delorie <dj@redhat.com>
> >
> > Alejandro Colomar <alx@kernel.org> writes:
> > > You forgot to sign.
> > 
> > I will never remember that... :-P
> > 
> > >> +The resulting data is read when a new process is created by
> > >> +.IR ld.so .
> > >
> > > Sorry for noticing this in v4; I forgot about it.  I see this unresolved
> > > issue from earlier versions remains.
> > 
> > A program is a file on disk.  A process is a running memory image.
> 
> Yup.  fork(3) creates a process (produces a new PID).  execve(2)
> replaces the image of the current process with a program read from disk
> (or in short, executes a program in the current process).
> 
> > 
> > Neither fork() nor exec() cause the tunables to be loaded, the process
> > itself has to do that.  For dynamic ELF programs/processes built with
> > glibc, ld.so does it before it passes control to the ELF image.  There
> > are other types of programs/processes that do not use ld.so and thus do
> > not read the tunables cache (which is called "ld.so.cache" for a reason ;-)
> 
> Hmmmmm, let's say you call execve(2) several times without any fork(2)s.
> Assuming a that the program paths that you pass to execve(2) are all
> dynamic ELF programs built with glibc, I guess for every time you call
> execve(2), ld.so(8) will be run, and the tunables stored in ld.so.cache
> will be used.  Is this correct?
> 
> 	#include <unistd.h>
> 	int
> 	main(int, char *argv[])
> 	{
> 		sleep(1);
> 		execve("proc/self/exe", argv, NULL);
> 	}

Oh, I thought this would work as a recursive infinite-loop program.  It
doesn't seem to work.  I guess there's some race condition?  :D

	alx@devuan:~$ cd tmp/
	alx@devuan:~/tmp$ cat ex.c 
	#include <unistd.h>
	int
	main(int, char *argv[])
	{
		sleep(1);
		execve("proc/self/exe", argv, NULL);
	}

	alx@devuan:~/tmp$ gcc -Wall -Wextra ex.c 
	alx@devuan:~/tmp$ time ./a.out 

	real	0m1.003s
	user	0m0.003s
	sys	0m0.000s


Cheers,
Alex

> 
> Let's also say you fork(2) several times, without any execve(2) calls.
> I suppose that won't trigger any of this, right?
> 
> 	#include <unistd.h>
> 	int
> 	main(void)
> 	{
> 		for (int i = 0; i < 10; i++) {
> 			sleep(1);
> 			fork();
> 		}
> 	}
> 
> From my understanding, only the first program will trigger this more
> than once, right?
> 
> If so, I'd use the same wording that execve(2) uses:
> 
> 	execve() executes the program referred to by path.
> 
> That is, execve(2) executes programs, and ld.so.cache is read when
> a program is executed (in the current process).
> 
> > 
> > I don't know how to say this clearly with fewer words...
> > 
> > >> +The syntax allows lines to start with the keyword
> > >> +.I include
> > >
> > > s/I/B/  (since it's a literal, not a variable)
> > 
> > Fixed.
> > 
> 
> 
> Cheers,
> Alex
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3525 bytes --]

> Date: 2026-08-07 02:11:04+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> > Date: 2026-08-07 02:07:00+0200
> > From: Alejandro Colomar <alx@kernel.org>
> >
> > Hi DJ,
> > 
> > > Date: 2026-08-06 18:15:15-0400
> > > From: DJ Delorie <dj@redhat.com>
> > >
> > > Alejandro Colomar <alx@kernel.org> writes:
> > > > You forgot to sign.
> > > 
> > > I will never remember that... :-P
> > > 
> > > >> +The resulting data is read when a new process is created by
> > > >> +.IR ld.so .
> > > >
> > > > Sorry for noticing this in v4; I forgot about it.  I see this unresolved
> > > > issue from earlier versions remains.
> > > 
> > > A program is a file on disk.  A process is a running memory image.
> > 
> > Yup.  fork(3) creates a process (produces a new PID).  execve(2)
> > replaces the image of the current process with a program read from disk
> > (or in short, executes a program in the current process).
> > 
> > > 
> > > Neither fork() nor exec() cause the tunables to be loaded, the process
> > > itself has to do that.  For dynamic ELF programs/processes built with
> > > glibc, ld.so does it before it passes control to the ELF image.  There
> > > are other types of programs/processes that do not use ld.so and thus do
> > > not read the tunables cache (which is called "ld.so.cache" for a reason ;-)
> > 
> > Hmmmmm, let's say you call execve(2) several times without any fork(2)s.
> > Assuming a that the program paths that you pass to execve(2) are all
> > dynamic ELF programs built with glibc, I guess for every time you call
> > execve(2), ld.so(8) will be run, and the tunables stored in ld.so.cache
> > will be used.  Is this correct?
> > 
> > 	#include <unistd.h>
> > 	int
> > 	main(int, char *argv[])
> > 	{
> > 		sleep(1);
> > 		execve("proc/self/exe", argv, NULL);

Dumb of me; missing leading '/'.  :)


Cheers,
Alex

> > 	}
> 
> Oh, I thought this would work as a recursive infinite-loop program.  It
> doesn't seem to work.  I guess there's some race condition?  :D
> 
> 	alx@devuan:~$ cd tmp/
> 	alx@devuan:~/tmp$ cat ex.c 
> 	#include <unistd.h>
> 	int
> 	main(int, char *argv[])
> 	{
> 		sleep(1);
> 		execve("proc/self/exe", argv, NULL);
> 	}
> 
> 	alx@devuan:~/tmp$ gcc -Wall -Wextra ex.c 
> 	alx@devuan:~/tmp$ time ./a.out 
> 
> 	real	0m1.003s
> 	user	0m0.003s
> 	sys	0m0.000s
> 
> 
> Cheers,
> Alex
> 
> > 
> > Let's also say you fork(2) several times, without any execve(2) calls.
> > I suppose that won't trigger any of this, right?
> > 
> > 	#include <unistd.h>
> > 	int
> > 	main(void)
> > 	{
> > 		for (int i = 0; i < 10; i++) {
> > 			sleep(1);
> > 			fork();
> > 		}
> > 	}
> > 
> > From my understanding, only the first program will trigger this more
> > than once, right?
> > 
> > If so, I'd use the same wording that execve(2) uses:
> > 
> > 	execve() executes the program referred to by path.
> > 
> > That is, execve(2) executes programs, and ld.so.cache is read when
> > a program is executed (in the current process).
> > 
> > > 
> > > I don't know how to say this clearly with fewer words...
> > > 
> > > >> +The syntax allows lines to start with the keyword
> > > >> +.I include
> > > >
> > > > s/I/B/  (since it's a literal, not a variable)
> > > 
> > > Fixed.
> > > 
> > 
> > 
> > Cheers,
> > Alex
> > 
> > -- 
> > <https://www.alejandro-colomar.es>
> 
> 
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[DJ Delorie]

Alejandro Colomar <alx@kernel.org> writes:
> Hmmmmm, let's say you call execve(2) several times without any fork(2)s.
> Assuming a that the program paths that you pass to execve(2) are all
> dynamic ELF programs built with glibc, I guess for every time you call
> execve(2), ld.so(8) will be run, and the tunables stored in ld.so.cache
> will be used.  Is this correct?

I think this rabbit hole is too deep for this part of the man page.  We
need a short sentence that's obvious to the reader, not a diatribe on
how the linux kernel works.

I'm happy with something like "The resulting data is read when the
program starts." regardless of how ambiguous or technically incorrect it
might be ;-)

Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

Hi DJ,

> Date: 2026-08-06 23:25:29-0400
> From: DJ Delorie <dj@redhat.com>
>
> Alejandro Colomar <alx@kernel.org> writes:
> > Hmmmmm, let's say you call execve(2) several times without any fork(2)s.
> > Assuming a that the program paths that you pass to execve(2) are all
> > dynamic ELF programs built with glibc, I guess for every time you call
> > execve(2), ld.so(8) will be run, and the tunables stored in ld.so.cache
> > will be used.  Is this correct?
> 
> I think this rabbit hole is too deep for this part of the man page.  We
> need a short sentence that's obvious to the reader, not a diatribe on
> how the linux kernel works.
> 
> I'm happy with something like "The resulting data is read when the
> program starts." regardless of how ambiguous or technically incorrect it
> might be ;-)

I'm not happy with starts, but if 's/starts/is executed/', or
alternatively 's/starts/& execution/', I'm happy.

'starts execution' is precisely the wording that execve(2) uses to
describe the moment when ld.so(8) is called.

     If the executable is an a.out  dynamically  linked  binary
     executable  containing shared‐library stubs, the Linux dy‐
     namic linker ld.so(8) is called at the start of  execution
     to  bring  needed  shared objects into memory and link the
     executable with them.

Does this sound good to you?


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 2/4] man/man5/tunables.conf: Document system-wide tunables config

[DJ Delorie]

I'm ok with :

  The resulting data is read when the program starts execution.

This is what I've got so far:

commit 8ed803ba1e814dd7efdeec787b9b278c2e44be83
Author: DJ Delorie <dj@redhat.com>
Date:   Fri Aug 7 23:07:04 2026 -0400

    man/man5/tunables.conf: Document system-wide tunables config
    
    Signed-off-by: DJ Delorie <dj@redhat.com>

diff --git a/man/man5/tunables.conf.5 b/man/man5/tunables.conf.5
new file mode 100644
index 000000000..a27f78cde
--- /dev/null
+++ b/man/man5/tunables.conf.5
@@ -0,0 +1,144 @@
+.TH tunables.conf 5 (date) "Linux man-pages (unreleased)"
+.SH NAME
+tunables.conf \- tunables configuration file
+.SH SYNOPSIS
+.nf
+.B /etc/tunables.conf
+.fi
+.SH DESCRIPTION
+Tunables are a feature in the GNU C Library
+that allows application authors and distribution maintainers
+to alter the runtime library behavior to match their workload.
+For a list of supported tunables,
+please consult the glibc manual
+that corresponds to your installed version of glibc,
+or run the following command:
+.P
+.in +4n
+.EX
+ld.so \-\-list\-tunables
+.EE
+.P
+The file is parsed by
+.BR \%ldconfig (8)
+and the results stored in
+.IR /etc/ld.so.cache .
+The resulting data is read when the program starts execution.
+.P
+Each line in the file
+.I /etc/tunables.conf
+specifies a tunable,
+which is specified with a string of the form
+.IB name = value \f[R].\f[]
+.P
+The syntax allows lines to start with the keyword
+.B include
+followed by a
+.BR \%glob (7)
+pattern.
+Files matching that pattern will be processed
+as if their contents were included at that point.
+.P
+Each line may include zero or more keywords or symbols at the beginning,
+which affect how each tunable affects each processes.
+The keywords must be separated by whitespace,
+but the symbols need not be.
+.TP
+.B overridable
+.TQ
+.B +
+Allow the tunable to be overridden by the
+.B GLIBC_TUNABLES
+environment variable when the process runs
+(this is the default).
+.TP
+.B nonoverridable
+.TQ
+.B \-
+Do not allow the tunable to be overridden by the environment variable.
+.TP
+.B onlysecure
+.TQ
+.B @
+The tunable applies only to
+.B AT_SECURE
+processes,
+such as one started from a set-user-ID program,
+or one with elevated capabilities.
+.TP
+.B nonsecure
+.TQ
+.B $
+The tunable applies only to
+.RB non- AT_SECURE
+processes (this is the default).
+.TP
+.B anysecure
+.TQ
+.B *
+The tunable applies to both
+.B AT_SECURE
+and
+.RB non- AT_SECURE
+processes.
+.P
+The file may also contain
+.IR filters ,
+which limit the tunables following it.
+The effects of a filter are terminated by
+any of the following:
+.IP \[bu] 3
+The end of the file.
+.PD 0
+.IP \[bu]
+The end of an included file.
+.IP \[bu]
+An
+.B include
+directive.
+.IP \[bu]
+A new (possibly empty) filter.
+.PD
+.P
+The syntax is:
+.P
+.in +4n
+.EX
+.BI [ filter : pattern ]
+.EE
+.in
+.TP
+.B proc
+The
+.B proc
+filter limits the following tunables to processes
+whose name matches the pattern.
+The pattern may be an absolute path
+or just the base name.
+.P
+A filter can also be empty:
+.BR [] .
+Such a filter has no effects.
+.SH FILES
+.TP
+.I /etc/tunables.conf
+.TP
+.I /etc/ld.so.cache
+cached copy of tunables
+.SH EXAMPLES
+Example configuration file:
+.P
+.in +4n
+.EX
+glibc.malloc.arenas_max=5
+onlysecure glibc.malloc.arenas_max=1
+\-glibc.pthread.rseq=1
+[proc:/bin/bad.program]
+\-glibc.pthread.rseq=0
+[proc:some.program]
+\-glibc.malloc.mmap_threshold=65536
+.EE
+.in
+.SH SEE ALSO
+.BR ld.so (8),
+.BR ldconfig (8)