IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
EINVAL means the kernel doesn't support it, ENODEV means it's
already revoked or the device is no longer there which has the same
effect anyway. All others - let's print an error to the logs.
We can easily hit the assertions without checking the internal states of
the DHCP client before calling these functions. That's annoying.
Let's do more gracefully.
When an interface enters the failed state, even if the DHCP client is
stopped, the acquired DHCP lease is not unreferenced, as the callback
dhcp4_handler() do nothing in that case. When the failed interface is
being reconfigured after that, the DHCP client is stopped again
(though it is already stopped), and SD_DHCP_CLIENT_EVENT_STOP event is
triggered and sd_dhcp_client_send_release() is called, and the
assertion in the function is triggered.
E.g.
===
systemd-networkd[98588]: wlp59s0: DHCPv4 address 192.168.86.250/24, gateway 192.168.86.1 acquired from 192.168.86.1
systemd-networkd[98588]: wlp59s0: Could not set DHCPv4 route: Nexthop has invalid gateway. Network is unreachable
systemd-networkd[98588]: wlp59s0: Failed
systemd-networkd[98588]: wlp59s0: State changed: configuring -> failed
systemd-networkd[98588]: wlp59s0: The interface entered the failed state frequently, refusing to reconfigure it automatically.
systemd-networkd[98588]: wlp59s0: DHCPv4 client: STOPPED
systemd-networkd[98588]: wlp59s0: DHCPv4 client: State changed: bound -> stopped
systemd-networkd[98588]: Got message type=method_call sender=:1.449 destination=org.freedesktop.network1 path=/org/freedesktop/network1 interface=org.freedesktop.network1.Manager member=ReconfigureLink ...
systemd-networkd[98588]: wlp59s0: State changed: failed -> initialized
systemd-networkd[98588]: wlp59s0: found matching network '/etc/systemd/network/50-wifi.network'.
systemd-networkd[98588]: wlp59s0: Configuring with /etc/systemd/network/50-wifi.network.
systemd-networkd[98588]: wlp59s0: DHCPv4 client: STOPPED
systemd-networkd[98588]: Assertion 'sd_dhcp_client_is_running(client)' failed at src/libsystemd-network/sd-dhcp-client.c:2197, function sd_dhcp_client_send_release(). Aborting.
===
When the interface is in the failed state, link_getlink_handler_internal()
will do nothing and return zero, thus the interface will not be
reconfigured, especially when the reconfiguration is triggered in
link_enter_failed().
Follow-up for c2eb7753dd.
In some kernels (specifically, 5.4) even though the clone3 syscall is
supported, setting CLONE_INTO_CGROUP is not. The error message returned
in this case is E2BIG.
If posix_spawn_wrapper encounters this error, it does not retry, and
cannot spawn any programs in said kernels.
This commit adds a check for the E2BIG error and retries pidfd_spawn()
without the POSIX_SPAWN_SETCGROUP flag.
If we encounter an E2BIG error, and the pidfd_spawn() succeeds after
removing the POSIX_SPAWN_SETCGROUP flag, then we cache the result so
that we do not retry every time.
Originally, this issue was reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077204.
Signed-off-by: Kornilios Kourtis <kornilios@gmail.com>
That indicates the interface name in 'iif' or 'oif' cannot be resolved
when 'ip rule' command is invoked. That's natural when networkd fail to
remove rule but the corresponding interface is already removed.
To make not the residual rules interfere subsequent test cases, let's
ignore the flag and actually remove unwanted rules.
Currently, these attributes are not configured by us, but there may be a
existing rule created by user manually with one of these attribute.
To correctly manage such foreign rules, let's read these attributes.
The kernel does not distinguish rules with different flags in
rule_exists(), but the flags of an existing rule cannot be updated.
Let's remove rules that have conflicting flags, and configure new rules
later with requested flags.
When we fail to remove a rule, that mostly means the rule does not exist
in the kernel anymore, e.g. already removed manually and we have not
received notification about that yet.
Let's detach the rule in that case.
Otherwise, if we fail to configure the rule, then the manager will keep
nonexistent rule forever. So, let's first copy the rule and put it on
Request, then on success generate a new copy based on the netlink
notification and store it to Manager.
This is the same as 0a0c2672db, but for
routing policy rule.
If it is already requested, the new request will be anyway silently refused by
link_queue_request_safe(), which returns 0 in such case. Let's return earlier.
There should be no functional change, just refactoring.
They are stored in Manager.rules set or Network.rules_by_section hashmap.
For safety, let's not edit them even temporarily.
No functional change, just refactoring.
being connected to a TTY is not really enough to determine
interactivity in many cases. Let's also check if we have a controlling
TTY.
Inspired by #34016
This will greatly reduce the number of cases where the global unicast
scope overlaps with link scopes configured as default-route, making it
feasible to use the global DNS setting in conjunction with per-link dns
servers configured by the network.
This change is preferred over demoting links to default-route=no where
the user prefers to use the network provided DNS servers, and I expect
it is non-disruptive in that it should not degrade the efficacy of any
existing configuration.
let's instead generate ENOTTY on our own. This is more correct with out
coding style (since we generally do not propagate errors via errno), and
also addresses #34039 as side effect. (#34039 really needs to be fixed
in musl though, too, this is just a work-around as side-effect).
Fixes: #34039
glibc returs EIO on ttys that are hung up. That's not really correct,
POSIX seems to disagree.
Work around this in our code, and turn this into a clean "1", since a
hung up tty doesn't stop being a tty just because it is hung up.
Background: https://github.com/systemd/systemd/pull/34039
In apply_one_mount(), in the MOUNT_EXTENSION_DIRECTORY case,
char **extension_release was used as a return pointer twice but only
cleaned up once in the end. Fix it by removing duplicate code that
was causing this issue.
Fixes issue introduced in 55ea4ef096.
Currently, only FIB_RULE_INVERT flag can be configurable, but for
simplicity and future extension, let's manage all flags.
No functional change, just refactoring.
The kernel parses FRA_SUPPRESS_PREFIXLEN as uint32_t, but internally
handled as signed integer and negative values as unset. Let's explicitly
specify the size of the variable.
No functional change, just refactoring.
