Otherwise, the check below is always fail.
```
if (FLAGS_SET(query_flags, SD_RESOLVED_NO_STALE) && j->until_valid < current)
```
Follow-up for 5ed91481ab.
The descriptions of various options are reworked: first say what protocol
actually is, i.e. describe what type of notification the manager waits
for. Only after that describe various steps and things the service should
do. Also, apply some paragraph breaks.
Instead of recommending Type=simple, recommend Type=exec. Say explicitly that
Type=simple, Type=forking are not recommended. Type=simple ignores failure in a
way that doesn't make any sense except as a historical accident. We introduced
'exec' instead of changing 'simple' to keep backwards-compatiblity, but
'simple' is not very useful. 'forking' works, but is inefficient: correctly
programming the interface requires a lot of work, and at runtime, the
additional one or two forks are just a waste of CPU resources. Furthermore, we
now understand that because of COW traps, they may also increase memory
requirements. There is really no reason to use 'forking', except if it's
already implemented and the code cannot be changed to use 'notify'.
Also, remove the recommendations to use Type=simple to avoid delaying boot. In
most cases, if the service can support notifications about startup, those
should be done.
Overall, for new services, "notify", "notify-reload", and "dbus" are the
types that make sense.
Some properties of address can be updated, but some cannot.
On reconfiguring an interface or restarting networkd, let's keep an
assigned address only when it can be updated later with the requested
setting, and otherwise drop it.
IPv6 address can update the peer address without removing the address.
If an address have a peer, but now we want to drop the peer, we need to
specify a null address in IFA_ADDRESS attribute.
IPv4 address cannot update the peer address, so let's specify peer
address only when necessary.
The logs would give no hint about the answer to most interesting question: why
we decided to return true or false from the program. If we find batteries
that are low or uncertain, log at info level.
The stub image may not have enough sections to cause enough PE header
space to be free for later expansion. Given that the stub is guaranteed
to be expanded we should always reserve enough sections for it.
This also bumps the reservation to 15. It doesn't add more space
compared to current builds but it more closely reflects the amount of
sections that a UKI could have in total if all optional sections are
used.
Fixes: #28593
The PE header size calculation failed to take the PE magic and coff
header size into account, which will lead to header truncation if we are
writing only 5 sections.
With the previous change, now Address objects under requesting are not
owned by Link object, hence we need to also search corresponding Address
object in the request queue.
Then, all addresses managed by a link really exist (unless the kernel
silently removes addresses).
By this change, now Address objects managed by Link and owned by Request
are decoupled, and always requested settings will be applied.
Fixes#25843.
This makes `manager_rtnl_process_address()`
- first read minimal information to get managed Address object,
- then update the managed Address object directly.
Previously, we updated the Address object managed by Link partially,
e.g. peer address did not updated.
This makes the managed Address object more consistent with the assigned
address.
The kernel manages neighbors by the destination address, and the
LinkLayerAddress is mutable. Let's manage neighbors in the same way, and
dedup settings.
Then, we can start IPv4ACD without adding corresponding Address object
to Link.
Hopefully, no functional change, just refactoring and preparation for
later commits.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Daan De Meyer
Jan Janssen
Kiran Vemula
Frantisek Sumsal