| Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is intended for net.*.conf.*.foo files. Setting just "default" is not very
useful because any interfaces present before systemd-sysctl is invoked are not
affected. Setting "all" is too harsh, because the kernel takes the stronger of
the device-specific setting and the "all" value, so effectively having a weaker
setting for specific interfaces is not possible. Let's add a way in which can
set "default" first and then all the others without "all".
|
|
|
|
net.ipv4.conf.default.xyz="
This reverts commits 1836bf9e1d70240c8079e4db4312309f4f1f91fd
and 9fefb9e3cdebcefa681672423d23ccc72ae6c165.
The race is reintroduced, and will be fixed later.
|
|
Fixup for 32458cc968.
|
|
We use those strings as hash keys. While writing "a...b" looks strange,
"a///b" does not look so strange. Both syntaxes would actually result in the
value being correctly written to the file, but they would confuse our
de-deplication over keys. So let's normalize. Output also becomes nicer.
Add test.
|
|
one_zero() is used later in the header...
|
|
We need to run sysctl also in containers, because the network
subtree is namespaces and may legitimately be writable. But logging
all "errors" at notice level creates unwanted noise.
Also downgrade message about missing sysctls to log_info. This might also be
relatively common when configuration is targeted at different kernel
versions. With log_debug it'll still end up in the logs, but isn't really worth
of "notice" most of the time.
https://bugzilla.redhat.com/show_bug.cgi?id=1609806
|
|
This allocation is a low level detail, and it seems nicer to keep it
out of run().
|
|
This section is loaded in a bunch of places, so this affects many
man pages.
1. point the reader to the synopsis section, which has the exact paths
that are used to load files.
2. put the "reference" part first, and recommendations later, in separate
paragraphs.
3. describe how individual settings and whole files are replaces.
Closes #12791.
|
|
flags for each path
This extends on d253a45e1c147f5174265d71d7419da7bd52a88b, and instead of
merging just a single flag from previous mount entries of
/proc/self/mountinfo for the same path we merge all three.
This shouldn't change behaviour, but I think make things more readable.
Previously we'd set MOUNT_PROC_IS_MOUNTED unconditionally, we still do.
Previously we'd inherit MOUNT_PROC_JUST_MOUNTED from a previous entry on
the same line, we still do.
MOUNT_PROC_JUST_CHANGED should generally stay set too. Why that? If we
have two mount entries on the same mount point we'd first process one
and then the other, and the almost certainly different mount parameters
of the two would mean we'd set MOUNT_PROC_JUST_CHANGED for the second.
And with this we'll definitely do that still.
This also adds a comment explaining the situation a bit, and why we get
into this situation.
|
|
Fixes: #14567
Alternative-To: #14569
|
|
|
