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.
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.
RFC4861 Neighbor Discovery – Sections 4.2 and 6.3.4
From section 4.2. Router Advertisement Message Format:
Cur Hop Limit 8-bit unsigned integer. The default value that
should be placed in the Hop Count field of the IP
header for outgoing IP packets. A value of zero
means unspecified (by this router).
If we don't have TPM support then `alg` is NULL and passing this to
table_new() means we'd get a table with only two columns instead of
three, leading up to a very confusing output:
$ build/systemd-analyze pcrs
System lacks full TPM2 support, not showing PCR state.
NR NAME
0 platform-code
- 1
platform-config -
2 external-code
- 3
external-config -
4 boot-loader-code
- 5
boot-loader-config -
6 -
- 7
...
Let's name the header in this case with a simple dash, as it's going
to be hidden anyway, to make the table nice again:
$ build/systemd-analyze pcrs
System lacks full TPM2 support, not showing PCR state.
NR NAME
0 platform-code
1 platform-config
2 external-code
3 external-config
4 boot-loader-code
5 boot-loader-config
6 -
7 secure-boot-policy
...
Yu Watanabe
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Jan Janssen
Kiran Vemula
Frantisek Sumsal
Susant Sahani