Zero lifetime in RA is special, and we should not assign possibly very
short lifetime addresses or friends.
This should not change anything at least now, preparation for later
commits. Note, DHCPv4 and v6 code also uses it, but sd-dhcp-client and
sd-dhcp6-client already filtered messages with zero lifetime. Hence,
the change should not affect DHCP code.
If the lifetime of the route is already expired, do not try to
configure it.
Fixes a use-after-free, as the Request object is already freed, thus, we
cannot use Route or Link stored in Request object.
IPv6 Neighbor Discovery lets us autoconfigure a link's IPv6 addresses,
routes, DNS servers, and DNS search domains by listening for Router
Advertisement (RA) packets broadcast by one or more routers on the link.
Each RA can contain zero or more "options," each describing one piece of
configuration (e.g. a single route).
Currently, when we receive an RA from a router, we delete any addresses,
routes, etc. that originated from that router's previous RAs unless
they're also present as options in the new RA.
That behavior is a violation of RFC 4861[1]. In Section 9, the RFC
states that
Senders MAY send a subset of options in different packets. ... Thus,
a receiver MUST NOT associate any action with the absence of an
option in a particular packet. This protocol specifies that
receivers should only act on the expiration of timers and on the
information that is received in the packets.
Several other passages in the RFC reiterate this. Section 6.2.3:
A router MAY choose not to include some or all options when sending
unsolicited Router Advertisements.
Section 6.3.4:
Hosts accept the union of all received information; the receipt of a
Router Advertisement MUST NOT invalidate all information received in
a previous advertisement or from another source.
At least one consumer router in production today, the Google Nest Wifi,
often sends RAs that omit its global IPv6 prefix. When current versions
of systemd-networkd receive those RAs, they immediately delete the
interface's global IPv6 address, which breaks IPv6 connectivity.
Fix the issue by removing the invalidation logic entirely. It's not
needed at all, since we already invalidate addresses, routes, and DNS
configuration when the interface goes down or their lifetimes expire.
This fix does have the side effect of preventing changes to the .network
file (e.g. denylisted prefixes, whether to add routes from RAs) from
taking effect as soon as a new RA arrives. Instead, a full interface
reconfiguration is needed. But triggering those changes on RA receipt
was already rather arbitrary and out of the administrator's control, so
I think this change is fine.
commit 69203fba70 ("network: ndisc: remove old addresses and routes
after at least one SLAAC address becomes ready") introduced this
behavior. commit 50550722e3 fixed it partially, by preventing one
router's RAs from invalidating another router's configuration.
[1] https://www.rfc-editor.org/rfc/rfc4861
Fixes: 69203fba70 ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready")
The code to evaluate the kernel command line option was busted because it
was doing 'return b == !!r' at a point where 'r > 0'. Thus we'd return "true"
in both cases:
$ SYSTEMD_PROC_CMDLINE=systemd.condition-first-boot build/systemd-analyze condition 'ConditionFirstBoot=true'
test.service: ConditionFirstBoot=true succeeded.
Conditions succeeded.
$ SYSTEMD_PROC_CMDLINE=systemd.condition-first-boot build/systemd-analyze condition 'ConditionFirstBoot=false'
test.service: ConditionFirstBoot=false succeeded.
Conditions succeeded.
We only use 'ConditionFirstBoot=true' in units, so this wasn't noticed.
But I think the logic is broken in general: the condition should evaluate as
true only during initial boot. If we rerun the units at later points, we should
not consider ConditionFirstBoot to be true.
Also, the first boot logic is also used in pid1 itself. AFAICT, for two
things: in first boot machine-id is initialized transiently (this allows
first-boot operations to be restarted if boot fails), and preset-all is
executed. But this logic was different and separate from the logic to
evaluate ConditionFirstBoot. The distinction is abolished, and the operations
in pid1 now use the same logic as ConditionFirstBoot, which means that the
kernel command line option is checked, and condition_test_first_boot()
just tests whether pid1 thinks we're in first boot.
This makes things easier to grok for the user: there's just one condition for
"first boot" and it applies to both pid1 and units.
$ SYSTEMD_LOG_LEVEL=debug build/systemd-firstboot --prompt-root-password
Found container virtualization systemd-nspawn.
Found /etc/locale.conf, assuming locale information has been configured.
Failed to read credential firstboot.keymap, ignoring: No such device or address
Prompting for keymap was not requested.
Found /etc/localtime, assuming timezone has been configured.
Prompting for hostname was not requested.
Found /etc/machine-id, assuming machine-id has been configured.
Found /etc/passwd and /etc/shadow, assuming root account has been initialized.
Creation of /etc/kernel/cmdline was not requested, skipping.
If the executable path is prefixed with "-", an exit code of the command
normally considered a failure (i.e. non-zero exit status or abnormal exit
due to signal) is recorded, but has no further effect and is considered
equivalent to success.
Let's honor this with `systemctl status`, and color ignored exit status
in yellow, not red.
This is useful for systems which don't have any fsck.
We already skip emitting the fsck dependency when the fsck.$fstype helper
is missing, but fstab-generator doesn't necessarily know the fstype when
handling the root= parameter.
Previously, systemd-fsck was started for these mounts and then exited
immediately because it couldn't find the fsck.$fstype helper.
Allows to skip check that ensures units must not be running.
I have a use case that would use reattach, except the orchestrator
is using a non-standard versioning scheme, so image matching cannot
work. As a workaround, need to be able to detach and then attach
manually, without stopping the units to avoid extended downtimes
and loss of FD store.
For now we can use it to send broken-down records of JSON via the
monitor logic, but one day we can certainly reuse for dumping the
caches, or to implement a ResolveRecord() varlink call one day.
The socket is only accessible to privileged clients anyway, no need to
add another (user unfriendly) restriction via opt-in setting. let's just
allow this for privileged clients, mirroring "busctl monitor", or
"tcpdump" and similar, which all just work if you have privs.
(This does not break API, since we never did a release witht the
"Monitor" dbus property or config setting in place, i.e. with
cb456374e0)
In many (most?) of our event loops we want to exit once SIGTERM/SIGINT
is seen. Add a common helper for that, that does the right things in a
single call.
So far we expected callers to block the signals manually. Which is
usually a good idea, since they should do that before forking off
threads and similar. But let's add a mode where we automatically block
it for the caller, to simplify things.
Otherwise, we provide misleading error message.
Before:
---
$ udevadm info /sys/class/foo
Bad argument "/sys/class/foo", expected an absolute path in /dev/ or /sys/ or a unit name: Invalid argument
---
After:
---
$ udevadm info /sys/class/foo
Unknown device "/sys/class/foo": No such device
---
