Other similar variables use the binary name underscorified and upppercased
(with "_BINARY" appended in some cases to avoid ambiguity). Add "S" to follow
the same pattern for systemd-cgroups-agent.
Based on the discussion in #16715.
Commit 428a9f6f1d freed u->pids which is
problematic since the references to this unit in m->watch_pids were no more
removed when the unit was freed.
This patch makes sure to clean all this refs up before freeing u->pids by
calling unit_unwatch_all_pids().
So far we only reported major state transitions like failure to acquire
the message. Let's report the initial failure after a few timeouts in
a new event type.
The number of timeouts is hardcoded as 3, since Windows seems to be using
that. I don't think we need to make this configurable out of the box. A
reasonable default may be enough.
They are not really boolean, because we have both ipv4 and ipv6, but
for each protocol we have either unset, no, and yes.
From https://github.com/systemd/systemd/issues/13316#issuecomment-582906817:
LinkLocalAddressing must be a boolean option, at least for ipv4:
- LinkLocalAddressing=no => no LL at all.
- LinkLocalAddressing=yes + Static Address => invalid configuration, warn and
interpret as LinkLocalAddressing=no, no LL at all.
(we check that during parsing and reject)
- LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the
DHCP one, an LL address must be acquired at start or after a short N
unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a
DHCP address is acquired, drop the LL address. If the DHCP address is lost,
re-adquire a new LL address.
(next patch will move in this direction)
- LinkLocalAddressing=fallback has no reason to exist, because LL address must
always be allocated as a fallback option when using DHCP. Having both DHCP
and LL address at the same time is an RFC violation, so
LinkLocalAdressing=yes correctly implemented is already the "fallback"
behavior. The fallback option must be deprecated and if present in older
configs must be interpreted as LinkLocalAddressing=yes.
(removed)
- And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL
address aren't required to be always set for every IPv6 enabled interface (in
this case, coexisting with static or dynamic address if any)? Shouldn't be
always =yes?
(good question)
This effectively reverts 29e81083bd. There is no
special "fallback" mode now, so the check doesn't make sense anymore.
This fixes the following warning:
```
parse_hwdb.py:120: UserWarning: warn_ungrouped_named_tokens_in_collection: setting results name 'SETTINGS*' on And expression collides with 'HZ' on contained expression
dpi_setting = (Optional('*')('DEFAULT') + INTEGER('DPI') + Suppress('@') + INTEGER('HZ'))('SETTINGS*')
```
Not sure about for the mount_matrix, but LGTM.com warns in that line,
and, adding Group() does not change the parse result.
This reverts the gist of da1921a5c3 and
0d9fca76bb (for ppc).
Quoting #17559:
> libseccomp 2.5 added socket syscall multiplexing on ppc64(el):
> https://github.com/seccomp/libseccomp/pull/229
>
> Like with i386, s390 and s390x this breaks socket argument filtering, so
> RestrictAddressFamilies doesn't work.
>
> This causes the unit test to fail:
> /* test_restrict_address_families */
> Operating on architecture: ppc
> Failed to install socket family rules for architecture ppc, skipping: Operation canceled
> Operating on architecture: ppc64
> Failed to add socket() rule for architecture ppc64, skipping: Invalid argument
> Operating on architecture: ppc64-le
> Failed to add socket() rule for architecture ppc64-le, skipping: Invalid argument
> Assertion 'fd < 0' failed at src/test/test-seccomp.c:424, function test_restrict_address_families(). Aborting.
>
> The socket filters can't be added so `socket(AF_UNIX, SOCK_DGRAM, 0);` still
> works, triggering the assertion.
Fixes#17559.
Lennart Poettering