man/man5/tunables.conf: Document system-wide tunables config
PATCH v5 2/4 man/man5/tunables.conf: Document system-wide tunables config
--- man/man5/tunables.conf.5 | 145 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 man/man5/tunables.conf.5
man/man5/tunables.conf.5 new file +145 -0
@@ -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)
Signature · 1 line
2.47.3
Alejandro Colomar
maintainerHi DJ,
Quoted 5 lines
Date: 2026-08-06 16:44:30-0400
From: DJ Delorie <[email protected]>---
You forgot to sign.
Quoted 27 lines
man/man5/tunables.conf.5 | 145 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 man/man5/tunables.conf.5man/man5/tunables.conf.5 new file +17
-0@@ -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
man/man5/tunables.conf.5 line 27
Quoted 10 lines
man/man5/tunables.conf.5 new file +10
-0+.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)
man/man5/tunables.conf.5 line 36
Quoted 9 lines
man/man5/tunables.conf.5 new file +9
-0+.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
Quoted 111 lines
man/man5/tunables.conf.5 new file +109
-0+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)Signature · 1 line
2.47.3
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 1 line · Alejandro Colomar
You forgot to sign.
I will never remember that... :-P
Quoted 5 lines
Quoted 2 lines
+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...
Quoted 4 lines
Quoted 2 lines
+The syntax allows lines to start with the keyword +.I include
s/I/B/ (since it's a literal, not a variable)
Fixed.
Alejandro Colomar
maintainerHi DJ,
Quoted 8 lines
Date: 2026-08-06 18:15:15-0400
From: DJ Delorie <[email protected]>Quoted 1 line · Alejandro Colomar
You forgot to sign.
I will never remember that... :-P
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
+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).
Quoted 6 lines
Neither
fork()norexec()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).
Quoted 10 lines
I don't know how to say this clearly with fewer words...
Quoted 4 lines
Quoted 2 lines
+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
Signature · 1 line
<https://www.alejandro-colomar.es>
Alejandro Colomar
maintainerQuoted 38 lines
Date: 2026-08-07 02:07:00+0200
From: Alejandro Colomar <[email protected]>Hi DJ,
Quoted 8 lines
Date: 2026-08-06 18:15:15-0400
From: DJ Delorie <[email protected]>Quoted 1 line · Alejandro Colomar
You forgot to sign.
I will never remember that... :-P
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
+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).
Quoted 6 lines
Neither
fork()norexec()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?
Quoted 7 lines
#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
Quoted 41 lines
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).
Quoted 10 lines
I don't know how to say this clearly with fewer words...
Quoted 4 lines
Quoted 2 lines
+The syntax allows lines to start with the keyword +.I include
s/I/B/ (since it's a literal, not a variable)
Fixed.
Cheers,
AlexSignature · 1 line
<https://www.alejandro-colomar.es>
Signature · 1 line
<https://www.alejandro-colomar.es>
Alejandro Colomar
maintainerQuoted 47 lines
Date: 2026-08-07 02:11:04+0200
From: Alejandro Colomar <[email protected]>Quoted 44 lines
Date: 2026-08-07 02:07:00+0200
From: Alejandro Colomar <[email protected]>Hi DJ,
Quoted 8 lines
Date: 2026-08-06 18:15:15-0400
From: DJ Delorie <[email protected]>Quoted 1 line · Alejandro Colomar
You forgot to sign.
I will never remember that... :-P
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
+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).
Quoted 6 lines
Neither
fork()norexec()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
Quoted 72 lines
Quoted 1 line
}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.outreal 0m1.003s user 0m0.003s sys 0m0.000sCheers,
AlexQuoted 41 lines
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).
Quoted 10 lines
I don't know how to say this clearly with fewer words...
Quoted 4 lines
Quoted 2 lines
+The syntax allows lines to start with the keyword +.I include
s/I/B/ (since it's a literal, not a variable)
Fixed.
Cheers,
AlexSignature · 1 line
<https://www.alejandro-colomar.es>Signature · 1 line
<https://www.alejandro-colomar.es>
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 5 lines · Alejandro Colomar
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 ;-)
Alejandro Colomar
maintainerHi DJ,
Quoted 10 lines
Date: 2026-08-06 23:25:29-0400
From: DJ Delorie <[email protected]>Quoted 5 lines · Alejandro Colomar
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?
Quoted 7 lines
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
Signature · 1 line
<https://www.alejandro-colomar.es>
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 <[email protected]> Date: Fri Aug 7 23:07:04 2026 -0400
man/man5/tunables.conf: Document system-wide tunables config
man/man5/tunables.conf.5 new file +144 -0
@@ -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)
Alejandro Colomar
maintainerHi DJ,
Quoted 7 lines
Date: 2026-08-07 23:08:10-0400
From: DJ Delorie <[email protected]>I'm ok with :
The resulting data is read when the program starts execution.
Nice! :)
Quoted 10 lines
This is what I've got so far:
commit
8ed803ba1e814dd7efdeec787b9b278c2e44be83Author: DJ Delorie <[email protected]> Date: Fri Aug 7 23:07:04 2026 -0400
man/man5/tunables.conf: Document system-wide tunables configSigned-off-by DJ Delorie <[email protected]>
Thanks! I've applied the patch. Still, a small question (I'll amend myself with the result of the answer).
Quoted 5 lines
man/man5/tunables.conf.5 new file +0
-0
[...]
man/man5/tunables.conf.5 line 115
Quoted 13 lines
man/man5/tunables.conf.5 new file +13
-0+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.
Is this also a glob(7) pattern? Or is it a literal name?
man/man5/tunables.conf.5 line 117
Quoted 2 lines
man/man5/tunables.conf.5 new file +2
-0+The pattern may be an absolute path +or just the base name.
Have a lovely day!
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 11 lines · Alejandro Colomar
man/man5/tunables.conf.5 line 115
Quoted 9 lines
+.BI [ filter : pattern ]
+.EE
+.in
+.TP
+.B procman/man5/tunables.conf.5 new file +4
-0+The +.B proc +filter limits the following tunables to processes +whose name matches the pattern.Is this also a glob(7) pattern? Or is it a literal name?
No, it matches /pattern/ exactly.
Alejandro Colomar
maintainerHi DJ,
Quoted 16 lines
Date: 2026-08-22 13:02:17-0400
From: DJ Delorie <[email protected]>Quoted 11 lines · Alejandro Colomar
man/man5/tunables.conf.5 line 115
Quoted 9 lines
+.BI [ filter : pattern ]
+.EE
+.in
+.TP
+.B procman/man5/tunables.conf.5 new file +4
-0+The +.B proc +filter limits the following tunables to processes +whose name matches the pattern.Is this also a glob(7) pattern? Or is it a literal name?
Quoted 1 line
No, it matches /pattern/ exactly.
Hmmm, then let's say file. Does that sound good to you?
Cheers,
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>
Alejandro Colomar
maintainerQuoted 9 lines
Date: 2026-08-22 19:43:17+0200
From: Alejandro Colomar <[email protected]>Hi DJ,
Quoted 4 lines
Date: 2026-08-22 13:02:17-0400
From: DJ Delorie <[email protected]>Alejandro Colomar <[email protected]> writes:
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
man/man5/tunables.conf.5 line 115
Quoted 9 lines
+.BI [ filter : pattern ]
+.EE
+.in
+.TP
+.B procman/man5/tunables.conf.5 new file +4
-0+The +.B proc +filter limits the following tunables to processes +whose name matches the pattern.
Another detail I noticed now: How is the process name taken?
Does it have to do with __progname?
Or is it the name of the program file that is loaded by exec(3)?
Cheers,
Alex
Quoted 13 lines
Quoted 4 lines
Quoted 2 lines
Is this also a glob(7) pattern? Or is it a literal name?
No, it matches /pattern/ exactly.
Hmmm, then let's say file. Does that sound good to you?
Cheers,
AlexSignature · 1 line
<https://www.alejandro-colomar.es>
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 1 line · Alejandro Colomar
Another detail I noticed now: How is the process name taken?
The kernel doesn't actually tell us the name of the file we're exec'd from. It passes an already open file descriptor. So we have to infer the file name from /proc/self/exe. If that isn't available, we use argv[0] (unless AT_SECURE) but that can be vastly different than /proc/self/exe as it's a separate parameter in the execve() call (hence unless AT_SECURE ;).
Alejandro Colomar
maintainerHi DJ,
Quoted 4 lines
Date: 2026-08-22 13:54:01-0400
From: DJ Delorie <[email protected]>Alejandro Colomar <[email protected]> writes:
Quoted 8 lines
Quoted 1 line
Another detail I noticed now: How is the process name taken?
The kernel doesn't actually tell us the name of the file we're exec'd from. It passes an already open file descriptor. So we have to infer the file name from
/proc/self/exe. If that isn't available, we use argv[0] (unlessAT_SECURE) but that can be vastly different than/proc/self/exeas it's a separate parameter in theexecve()call (hence unlessAT_SECURE;).
Hmmmm; interesting! I'll push your patch already, as is, and work on a patch (set) of my own to improve it a little bit. I'll send you the patch (set) for discussion. Thanks!
Have a lovely night!
Alex
Signature · 1 line
<https://www.alejandro-colomar.es>
Quoted 3 lines · Alejandro Colomar
Quoted 1 line
Quoted 1 line
Quoted 1 line
+.BI [ filter : pattern ]
Hmmm, then let's say file. Does that sound good to you?
I mean the "pattern" in the syntax, for this filter, must match the - well, whatever we call /proc/self/exe (or if that's unavailable, argv[0]) - for the process. As noted, it must exactly match either the entirety of /proc/self/exe or just the basename of it, depending.
So if you want to say "limits the following tunables to processes whose file name (taken from /proc/self/exe) matches /pattern/" that's OK.
Saying "whose name matches the file" would be wrong, but I don't think you meant that.