Otherwise, initrd-cleanup.service requests isolation thus the socket
is stopped before switching root, and several early events after
switching root may be lost.
Continuation of #36734
Apparently I was wrong about everything under `/proc/` being seq_file,
but at least there're some more to convert and we can leverage our
helper func while doing so.
Currently, if systemd-networkd-wait-online is started with --dns, and
systemd-resolved is not running, it will exit with an error right away.
Similarly, if systemd-resolved is restarted while waiting for DNS
configuration, systemd-networkd-wait-online will not attempt to
re-connect, and will potentially never see subsequent DNS
configurations.
Improve this by adding socket units for the systemd-resolved varlink
servers, and re-establish the connection in systemd-networkd-wait-online
when we receive `SD_VARLINK_ERROR_DISCONNECTED`.
A host can send Router Advertisements (RAs) without acting as a router.
In such cases, the lifetime of the RA header should be zero, but may
contain several options, and clients can configure addresses, routes,
and so on with the message. The host may (should?) send Neighbor
Announcements (NAs) without the router flag in that case.
So, when a NA without the router flag is received, let's not drop
configurations based on the previous RA options, but only drop the
default gateway configured based on the RA header.
See RFC 4861 Neighbor Discovery in IPv6, section 6.3.4:
https://www.rfc-editor.org/rfc/rfc4861#section-6.3.4:~:text=%2D%20The%20IsRouter%20flag,as%20a%20host.
> - The IsRouter flag in the cache entry MUST be set based on the Router
> flag in the received advertisement. In those cases where the IsRouter
> flag changes from TRUE to FALSE as a result of this update, the node
> MUST remove that router from the Default Router List and update the
> Destination Cache entries for all destinations using that neighbor as
> a router as specified in Section 7.3.3. This is needed to detect when
> a node that is used as a router stops forwarding packets due to being
> configured as a host.
Fixes a regression caused by 87a33c0740 (v256).
Fixes#37198.
This is analogous to #36123, but for Tun/Tap interfaces created by
systemd-networkd.
If a regular user account want to control a Tun/Tap interface, then
assign the interface to a system group, e.g., vpn, and add the user
to the group.
Closes#37279.
and ignore the settings if we cannot find the specified user/group.
This also replaces get_user_creds()/get_group_creds() with
userdb_by_name()/groupdb_by_name().
When a [SR-IOV] section has no setting, e.g.
```ini
[SR-IOV]
VirtualFunction=0
```
then the kernel previously replied -EINVAL, as we send a rtnl message
with an empty IFLA_VF_INFO container.
See See do_setvfinfo() in net/core/rtnetlink.c of the kernel.
When a [SR-IOV] section that has an unsupported settings by the
interface driver, then previously the kernel partially applied
settings and returned -EOPNOTSUPP. E.f.
```ini
[SR-IOV]
VirtualFunction=0
LinkState=auto
Trust=true
MACAddress=02:01:00:3e:61:34
```
and the interface does not support configuring the link state, then
the MAC address is assigned, but the trust is not applied:
```
enp3s0f0: Failed to configure SR-IOV virtual function 0, ignoring: Operation not supported
vf 0 link/ether 02:01:00:3e:61:34 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
```
To fix such issues, this makes networkd/udevd send each attribute
for VF one-by-one.
Fixes#37257 and #37275.
The configuration can easily fail when the target virtual function
does not exist, and there is nothing networkd can do in such case.
Also, it is overkill to make the physical interface entered to the
failed state in such case. Let's warn but ignore the failure.
The header requires struct sockaddr declared. So, otherwise, we need to
include sys/socket.h earlier than linux/vm_sockets.h.
Let's make the header includable at any place.
Follow-up for 511619087b.
Notable changes are
- SIGTERM is the highest among others, to make not udevd queue too
many events, as we need to serialize them anyway.
- device monitor has the second highest priority, to make 'remove'
uevents received earlier than IN_IGNORED inotify events. Otherwise,
after IN_IGNORED is received, if there is no queued event,
/run/udev/queue file will be removed by the post-event source of the
inotify event, and 'udevadm settle' or friends may wrongly finish,
even we will soon queue 'remove' uevents for the device.
This change should fix the recent instability of TEST-64-UDEV-STORAGE.
For other changes, see the comments in the code.
Note, it should be safe even if we synthesize no event, e.g. when the
device has been already removed. In such case, the post event after
SIGCHLD will remove the file.
This is mostly a paranoia, but if we failed to create /run/udev/queue
for some reasons on queueing an event, previously we would never create
the file until once the queue became empty. This makes in such case we
try to create the file again when queueing the next event.
RFC 5227 specifies randomized intervals to avoid that a large number of
hosts powered up at the same time send their message simultaneously.
Performing the conflict detection takes a variable time between 4 and 7
seconds from the beginning to the first announcement, as shown by the
following diagram where P indicates a probe and A an announcement:
```
time(s) 0 1 2 3 4 5 6 7 8 9
+---+---+---+---+---+---+---+---+---+
SHORTEST P P P A A
LONGEST P P P A A
```
The host can't use the address until the first announcement is sent. 7
seconds is a very long time on modern computers especially considering
the fact that the round-trip time on current LAN technologies is at most
few milliseconds. Section 2.2 of the RFC addresses this matter and hints
that a future standard will adjust those timeouts; however that standard
doesn't exist yet.
Make the timeout configurable via a new
"IPv4DuplicateAddressDetectionTimeoutSec=" option. The intervals defined
in the RFC are then scaled proportionally so that the duration of the
conflict detection takes at most the given value. Interval happening
after the first announcement are not scaled, as recommended by the RFC.
Also reduce the default value from 7s to 200ms, which is a more suitable
value for today's technology.
Previous code assumed that both family and address are read when
-EINVAL, hence the following read of port and name could succeed.
Let's drop the assumption, and skip reading remaining elements.
No functional change, just refactoring and preparation for later change.
For example, consider the following device:
- syspath: /sys/bus/mdio_bus/drivers/Qualcomm Atheros AR8031!AR8033
- subsystem: "drivers"
- driver subsystem: "mdio_bus"
- sysname: "Qualcomm Atheros AR8031/AR8033" <-- '!' is replaced with '/'
When sd_device_new_from_subsystem_sysname() is called to get the device,
the arguments to sd_device_new_from_subsystem_sysname() should be
- subsystem: "drivers"
- sysname (concatenated with driver subsystem): "mdio_bus:Qualcomm Atheros AR8031/AR8033"
In that case, we need to pass to device_new_from_path_join() the following:
- subsystem: "drivers"
- driver subsystem: "mdio_bus"
- sysname: "Qualcomm Atheros AR8031/AR8033"
- a: "/sys/bus"
- b: "drivers"
- c: "mdio_bus"
- d: "Qualcomm Atheros AR8031!AR8033"
Here, the important point is that the `sysname` argument and the
last argument `d` are differnt: the `sysname` argument needs to match
the sysname obtained by `sd_device_get_sysname()`, but `d` must be
the last path component of the syspath.
Previously, we passed a wrong sysname to device_new_from_path_join().
This fixes the issue.
Fixes a bug in cd7c71154c (v257).
The test does not request each unit file exists, but keeping legacy unit
names in test sounds spurious. Let's remove them. Hopefully we still
have enough test cases.
The method is deprecated since 64f173324e
(v257) and announced that it will be removed in v258.
Let's remove it now.
This effectively reverts 84c01612de.
We can run sd-ipv4ll/sd-ipv4acd also on an interface with IFF_NOARP
flag, but that may cause address conflict with other hosts.
Let's enable ARPing when sd-ipv4ll/sd-ipv4acd are enabled unless ARP= is
explicitly disabled.
To make systemd-udevd not lose received uevents on restart. This may be
important on switching root, even though we typically trigger all devices
after switching root by systemd-udev-trigger.service, but it may be
disabled or modified by admin.
Currently, all use cases of notify_push_fd()/notify_push_fdf()
assume that the name of each fd in the fdstore is unique.
For safety, let's remove the existing fds before pushing a new one
to avoid multiple fds with the same name stored in the fdstore.
Yu Watanabe