Previously, event if link's setup state is in failed, tests may pass,
as systemd-networkd-wait-online success if the state is in failed state.
This makes tests be checked more strictly.
Some path of configuring address, route or etc., go to failed state, but
some do not. E.g., failure in address configuration which is provided by
DHCPv4 goes to failed state, but static address does not.
This is just for consistency. This should not change anything if
everything is fine.
This also voidify manager_rtnl_process_address().
"systemctl --failed" suggested I pass "--all" to see units in the inactive
state as well. I thought this was not very useful. If you explicitly
asked for units in a specific state, then you already know you have
narrowed it down. And if you ran "systemctl --state=inactive", it is even
more strange to see this message.
@keszybz suggests we probably don't want to suggest "list-unit-files"
either :-). Let's only suggest that if the user passed "--state=inactive".
Finally, this means the output for "systemctl --failed" could be just
"0 loaded units listed". In this case, we don't need any highlight on that
text, to distinguish it from the hint. This matches "list-unit-files".
This also means we happen to avoid using red highlight, when there are zero
failed units, as if that itself was a failure. @kesbyz pointed out that
old behaviour was a bit weird.
Current operation of system-update-cleanup.service (removing /system-update
symlink and rebooting) implies that any update must complete *before*
system-update.target is reached.
Update recommendations to include explicitly setting
Before=system-update.target in services that use offline-updates mode.
Signed-off-by: Michael Zhivich <mzhivich@akamai.com>
Let's hide non-UTF-8 locales by default. It's 2019 after all.
Let's add an undocumented env var to reenable listing them though.
This should substantially shorten the list of choices we offer users,
and only show realistic choices.
note that only firstboot and localectl make use of this information, and
both allow configuration of values outside of these lists, hence all
this change does is hide legacy options, but they are still available if
you know what you do, and that's how it should be.
When DHCP or any other dynamic addresses are changed, then
link_request_set_routes() is invoked, and even if no static routes
are configured, the operational state is needlessly changed to
configuring state.
This makes the state is changed only when static routes are configured.
Let's remove some unnecessary confusion around signed/unsigned types for
log levels. Let's just stick to signed, because that is what glibc
generally appears to use.
While we are at it, add explicit logging for all error causes.
let's add [static] where it was missing so far
Drop [static] on parameters that can be NULL.
Add an assert() around parameters that have [static] and can't be NULL
hence.
Add some "const" where it was forgotten.
Let's drop the 'static' logic when a parameter can be NULL.
I think asan/ubsan are right here, judging by the C99 spec language:
"A declaration of a parameter as ‘‘array of type’’ shall be adjusted to
‘‘qualified pointer to type’’, where the type qualifiers (if any) are
those specified within the [ and ] of the array type derivation. If the
keyword static also appears within the [ and ] of the array type
derivation, then for each call to the function, the value of the
corresponding actual argument shall provide access to the first element
of an array with at least as many elements as specified by the size
expression."
If we specify NULL, then we certainly don't pvode access to any valid
array.
Fixes: #13039
