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".
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.
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 extends on d253a45e1c, 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.
This changes nss-systemd to use the new varlink user/group APIs for
looking up everything.
(This also changes the factory /etc/nsswitch.conf line to use for
hooking up nss-system to use glibc's [SUCCESS=merge] feature so that we
can properly merge group membership lists).
Fixes: #12492
This way we can use libxcrypt specific functionality such as
crypt_gensalt() and thus take benefit of the newer algorithms libxcrypt
implements. (Also adds support for a new env var $SYSTEMD_CRYPT_PREFIX
which may be used to select the hash algorithm to use for libxcrypt.)
Also, let's move the weird crypt.h inclusion into libcrypt.h so that
there's a single place for it.
Previously we'd allow marking TTY sessions as idle, but when the user
tried to unmark it as idle again it we'd just revert to automatic TTY
atime idle detection, thus making it impossible to mark the session as
non-idle, unless its TTY is atime-touched all the time. But of course,
marking a session as idle is pretty much fatal if you never can mark it
as non-idle again.
This change is triggred by bug reports such as this:
https://github.com/systemd/systemd/issues/14053
With this patch we will now output a clean, clear error message if a
client tries to manipulate the idle state of a non-graphical session.
This means we now have clear rules: "manual" idle logic for graphical
sessions, and TTY based ones for all others that have a TTY of some
form.
I considered allowing the idle state to be overriden both ways for tty
sessions but that's problematic: for sessions that are temporarily
upgraded from tty to graphical and thus suddenly want to manage their
own idle state we'd need to a way to detect when the upgrade goes away
and thus we should revert to old behaviour. Without reverting to the
previous TTY idle auto-magic we'd otherwise be stuck in an eternally
idle or eternally non-idle state, with really bad effects in case
auto-suspend is used. Thus, let's instead generate a proper error
message, saying clearly we don't support it.
(Also includes some other fixes and clean-ups in related code)
Closes: #14053
We'd just print nothing and exit with 0. If the user gave an explicit
name, we should fail. If a pattern didn't match, we should at least warn.
$ networkctl status enx54ee75cb1dc0a* --no-pager && echo $?
No interfaces matched.
0
$ networkctl status enx54ee75cb1dc0a --no-pager
Interface "enx54ee75cb1dc0a" not found.
1
When starting a mount unit, systemd invokes mount command and moves the
unit's internal state to "mounting". Then it watches for updates of
/proc/self/mountinfo. When the expected mount entry newly appears in
mountinfo, the unit internal state is changed to "mounting-done".
Finally, when systemd finds the mount command has finished, it checks
whether the unit internal state is "mounting-done" and changes the state
to "mounted".
If the state was not "mounting-done" in the last step though mount command
was successfully finished, the unit is marked as "failed" with following
log messages:
Mount process finished, but there is no mount.
Failed with result 'protocol'.
If daemon-reload is done in parallel with starting mount unit, it is
possible that things happen in following order and result in above failure.
1. the mount unit state changes to "mounting"
2. daemon-reload saves the unit state
3. kernel completes the mount and /proc/self/mountinfo is updated
4. daemon-reload restores the saved unit state, that is "mounting"
5. systemd notices the mount command has finished but the unit state
is still "mounting" though it should be "mounting-done"
mount_setup_existing_unit() should take into account that MOUNT_MOUNTING
is transitional state and set MOUNT_PROC_JUST_MOUNTED flag if the unit
comes from /proc/self/mountinfo so that mount_process_proc_self_mountinfo()
later can make state transition from "mounting" to "mounting-done".
Fixes: #10872
