Sometimes, non-ramfs initrd root are useful. Eg, for kdump, because
initramfs is memory consuming, so mount a compressed image in earlier
initrd, chroot into it then let systemd do the rest of job is a good
solution.
But systemd doesn't recognize the initrd environment if rootfs is not a
temporary fs. This is a reasonable check, because switch-root in initrd
will wipe the whole rootfs, will be a disaster if there are any
misdetect.
So extend SYSTEMD_IN_INITRD environment variable, now it accepts boolean
value and two extra keyword, "auto" and "lenient". "auto" is same as
before, and it's the default value. "lenient" will let systemd bypass
the rootfs check.
The `quote` char variable ectually contains a character, not a pointer
or boolean. hence do an explicit comparison rather than rely on C's
downgrade to bool feature, as per our coding style.
This uses GREEDY_ALLOC_ROUND_UP() to grow the allocation size
exponentially. This should speed allocation loops up a bit, given
that we often call strextend() repeatedly in a loop on the same
buffer.
If users do not enable a service like systemd-time-wait-sync.target
(because they don't want to delay boot for external events, such as an
NTP sync), then timers should still take the the weaker time-set.target
feature into account, so that the clock is at least monotonic.
Hence, order timer units after both of the targets: time-sync.target
*and* time-set.target. That way, the right thing will happen regardless
if people have no NTP server (and thus also no
systemd-time-wait-sync.service or equivalent) or, only have an NTP
server (and no systemd-time-wait-sync.service), or have both.
Ordering after time-set.target is basically "free". The logic it is
backed by should be instant, without communication with the outside
going on. It's useful still so that time servers that implement the
timestamp from /var/ logic can run in later boot.
So the currentl and only fd_is_mount_point() check is actually entirely
bogus: it passes "/" as filename argument, but that's not actually a
a valid filename, but an absolute path.
fd_is_mount_point() is written in a way tha the fd refers to a directory
and the specified path is a file directly below it that shall be
checked. The test call actually violated that rule, but still expected
success.
Let's fix this, and check for this explicitly, and refuse it.
Let's extend the test and move it to test-mountpoint-util.c where the
rest of the tests for related calls are placed.
Replaces: #18004Fixes: #17950
In hostnamed this is exposed as a dbus property, and in the logs in both
places.
This is of interest to network management software and such: if the fallback
hostname is used, it's not as useful as the real configured thing. Right now
various programs try to guess the source of hostname by looking at the string.
E.g. "localhost" is assumed to be not the real hostname, but "fedora" is. Any
such attempts are bound to fail, because we cannot distinguish "fedora" (a
fallback value set by a distro), from "fedora" (received from reverse dns),
from "fedora" read from /etc/hostname.
/run/systemd/fallback-hostname is written with the fallback hostname when
either pid1 or hostnamed sets the kernel hostname to the fallback value. Why
remember the fallback value and not the transient hostname in /run/hostname
instead?
We have three hostname types: "static", "transient", fallback".
– Distinguishing "static" is easy: the hostname that is set matches what
is in /etc/hostname.
– Distingiushing "transient" and "fallback" is not easy. And the
"transient" hostname may be set outside of pid1+hostnamed. In particular,
it may be set by container manager, some non-systemd tool in the initramfs,
or even by a direct call. All those mechanisms count as "transient". Trying
to get those cases to write /run/hostname is futile. It is much easier to
isolate the "fallback" case which is mostly under our control.
And since the file is only used as a flag to mark the hostname as fallback,
it can be hidden inside of our /run/systemd directory.
For https://bugzilla.redhat.com/show_bug.cgi?id=1892235.
No functional change, just moving a bunch of things around. Before
we needed a rather complicated setup to test hostname_setup(), because
the code was in src/core/. When things are moved to src/shared/
we can just test it as any function.
The test is still "unsafe" because hostname_setup() may modify the
hostname.
This commit extends $SYSTEMD_COLORS to an enum variable (compared to
a simple boolean) which specifies the "colors mode". This means that, in
addition to disabling colors altogether, it's now possible to restrict
the console output to 16 or 256 colors only.
Let's clean up hostname_is_valid() a bit: let's turn the second boolean
argument into a more explanatory flags field, and add a flag that
accepts the special name ".host" as valid. This is useful for the
container logic, where the special hostname ".host" refers to the "root
container", i.e. the host system itself, and can be specified at various
places.
let's also get rid of machine_name_is_valid(). It was just an alias,
which is confusing and even more so now that we have the flags param.
The commit 6f3ac0d517 drops the prefix and
suffix in TAGS= property. But there exists several rules that have like
`TAGS=="*:tag:*"`. So, the property must be always prefixed and suffixed
with ":".
Fixes#17930.
Back in 5248e7e1f1 (July 2017) we moved over to
"_gateway", with the old name declared to be temporary measure. Since we're
doing a bunch of changes to resolved now, it seems to be a good moment to make
this simplification and not add support for the compat name in new code.
On really old kernels (< 4.14+) a bug in /proc/1/sched handling in the
kernel could be used to determine whether we are running in a PID
namespace. This hasn't worked for a long time, and there's little point
in making things work on old kernels we can't make work on current
kernels, hence let's drop that old cruft.
See: #8153
