This variable is not set by meson, so let's not try to use it.
We could use some more elaborate scheme (e.g. based on $MESON_BUILD_ROOT and
$MESON_SUBDIR) to find the path to systemd-sysv-generator, but it seems
that plain ./systemd-sysv-generator works just as well and has the advantage
that it's easy to invoke the test by hand (as long as one cd's to the
meson build dir).
When we are receiving address lifetime valid and lifetime preferred
'0' we set them via ndisc. That makes is shows as depricated and we
treat this as not ready.
In link_check_ready we look for whether address is depricated and
since this is depricated we never configure this link.
Thanks to Marc Haber <mh+github@zugschlus.de>
lifetime 0 a valid, and common, use case. It enables an installation to
autoconfigure systems in a way that they become immediately reachable
without needing local configuration after they have been turned on (for
example, for remote configuration). The local admin can then configure
additional, static IP addresses to be used for the server's service (and
the IP adress _only_, while the rest of network configuration still comes
from autoconfiguration), while _KEEPING_ the possibiltiy to reach the
system over the autoconfigured address in the case that static
configuration fails.
The correct way is to handle the announcement exactly as it is correctly
handled in the released software: It configures the address as
"deprecated", causing the kernel to accept packets addresses to it, and
not to use it for outgoing packets/connections _UNLESS_ there is no other
way to send the packet out.
The only change that is needed is that systemd-networkd should not wedge
itself in that case, it should just continue working (with two IP
addresses configured on the interface).
An IPv6 address with a remamining lifetime of zero is _NOT_ like an
expired IPv4 DHCP lease, it's still a valid and useable IP address. It
is just that the network advises the host not to use the address any
more for outgoing traffic _UNLESS_ there is no other way to send the
traffic.
Fixes#6359
$ systemctl show systemd-journald -p UID,GID
UID=4294967295
GID=4294967295
↓
$ systemctl show systemd-journald -p UID,GID
UID=[not set]
GID=[not set]
Just seeing the number is very misleading.
Fixes#6511.
Let's read one byte more than the file size we read from stat() on the
first fread() invocation. That way, the first read() will already be
short and indicate eof to fread().
This is a minor optimization, and replaces #3908.
LONG_LINE_MAX is much like LINE_MAX, but longer.
As it turns out LINE_MAX at 4096 is too short for many usecases. Since
the general concept of having a common maximum line length limit makes
sense let's add our own, and make it larger (1MB for now).
read_line() is much like getline(), and returns a line read from a
FILE*, of arbitrary sizes. In contrast to gets() it will grow the buffer
dynamically, and in contrast to getline() it will place a user-specified
boundary on the line.
Due to the chown() logic socket units might end up with processes even
if no explicit command is defined for them, hence let's make sure these
processes are in the right cgroup, and that means within a slice.
Mount, swap and service units unconditionally are assigned to a slice
already, let's do the same here, too.
(This becomes more important as soon as the ebpf/firewall stuff is
merged, as there'll be another reason to fork off processes then)
On cgroupsv2 we should also chown()/chmod() the subtree_control file,
so that children can use controllers the way they like.
On cgroupsv1 we should also chown()/chmod() cgroups.clone_children, as
not setting this for new cgroups makes little sense, and hence delegated
clients should be able to write to it.
Note that error handling for both cases is different. subtree_control
matters so we check for errors, but the clone_children/tasks stuff
doesn't really, as it's legacy stuff. Hence we only log errors and
proceed.
Fixes: #6216
These errors don't really matter, that's why we log and proceed in the
current code. However, we currently log at LOG_WARNING, but we really
shouldn't given that this is library code. Hence downgrade this to
LOG_DEBUG.
We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/
towards the user unit being "enabled", because the symlinks were not
located in "config" paths. But this is confusing to users, since those units
are clearly enabled and will be started. So let's muddle the definition of
enablement a bit to include the paths only accessible to root when looking for
enabled user units.
Fixes#4432.
I think this matches the spirit of "indirect" well: the unit
*might* be active, even though it is not "installed" in the
sense of symlinks created based on the [Install] section.
The changes to test-install-root touch the same lines as in the previous
commit; the change in each case is from
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_ENABLED)
to
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_DISABLED)
to
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_INDIRECT)
in the last two commits.
When a unit has a symlink that makes an alias in the filesystem,
but that name is not specified in [Install], it is confusing
is the unit is shown as "enabled". Look only for names specified
in Alias=.
Fixes#6338.
v2:
- Fix indentation.
- Fix checking for normal enablement, when the symlink name is the same as the
unit name. This case wasn't handled properly in v1.
v3:
- Rework the patch to also handle templates properly:
A template templ@.service with DefaultInstance=foo will be considered
enabled only when templ@foo.service symlink is found. Symlinks with
other instance names do not count, which matches the logic for aliases
to normal units. Tests are updated.
Let's permit installing BPF programs in cgroup subtrees if
Delegeate=yes. Let's not document this precise behaviour for now though,
as most likely the logic here should become recursive, but that's only
going to happen if the kernel starts supporting that. Until then,
support this in a non-recursive fashion.
The <!-- --> comment lines resulted in double newlines in the man page
header, which looks quite ugly. Let's rearrange a bit so that these
comments don't result in changes in the output.
