Currently, if for example a traffic control object already exist, networkd
will silently do nothing, even if the settings in the network file for the
traffic control object have changed. Let's instead replace the object if it
already exists so that new settings from the network file are applied as
expected.
Fixes#31226
This fixes a bug introduced during review of sysupdated. Originally,
we just returned EALREADY verbatim to signify that the target is
already up-to-date. Then we switched this to a proper error
(org.freedesktop.sysupdate1.NoCandidate) during review. But that now
maps to EIO, not EALREADY. Thus, whenever there's nothing to update,
updatectl would report I/O errors to the user, even though nothing
actually went wrong.
Follow-up for bab889c51e (#33032).
Currently, they unconditionally returns EPOLLIN and USEC_INFINITY, respectively.
Just for consistency with sd-bus, sd-journal, sd-varlink, and so on. All
they have _get_fd(), _get_events(), and _get_timeout().
Closes#34094.
As workarounded by fc0cbed2db, the pair of
subsystem and sysname is not unique. For examples,
- /sys/bus/gpio and /sys/class/gpio, both have gpiochip%N. However, these point to different devpaths.
- /sys/bus/mdio_bus and /sys/class/mdio_bus,
- /sys/bus/mei and /sys/class/mei,
- /sys/bus/typec and /sys/class/typec, and so on.
Let's refuse to provide sd_device object in such cases.
To create the sd_device object of a driver, the function
sd_device_new_from_subsystem_sysname() requires "drivers" for subsystem
and e.g. "pci:iwlwifi" for sysname. Similarly, sd_device_new_from_device_id()
also requires driver subsystem. However, we have never provided a
way to get the driver subsystem ("pci" for the previous example) from
an existing sd_device object.
Let's introduce a way to get driver subsystem.
This partially reverts the commit 730b76bd2c.
Before the commit, the function returned 0 on success, but the commit
made the function always return 1, as if device->devtype is NULL, the
function returns -ENOENT in the above.
Fortunately, udev_device_get_devtype() does not propagate any
non-negative value from sd_device_get_devtype(). Hence, hopefully we can
safely revert the change.
This fixes the following issues:
- We have a journal file, which contains entries of boot A and B. Let T
be the timestamp of the _last_ entry of boot A.
If sd_journal_seek_monotonic_usec() is called for boot A with a timestamp
_after_ T, following sd_journal_next() will provide the _first_ entry of
boot A, rather than the first entry of boot B.
- We have two journal files X and Y. The file X contains entries of boot A.
Let T be the timestamp of the _last_ entry of boot A in file X. The file Y
contains entries of boot A after timestamp T.
If sd_journal_seek_monotonic_usec() is called for boot A with a
timestamp _after_ T, following sd_journal_next() will provide the
_first_ entry of boot A, whose timestamp is of course earlier than T.
To make it work without sd-event.
Prompted by recent chat:
> Hey all!
> reading man libudev, it says to use sd-device instead now. I've read that
> APIs header file and it seems it no longer has an equivalent to libudev's
> udev_monitor_get_fd, which AFAICT means I have to use sd-event to watch
> for events I'm interested in. I know I can "embed" sd-event in other event
> loops I might already have, but that seems overkill when I'm only interested
> in this one type of event and don't need sd-event for anything else.
Previously, the main process of systemd-udevd manages worker process
with their sd_device_monitor object to save the destination address.
Let's save only destination address, and drop worker's sd_device_monitor
object.
Previously, device_monitor_enable_receiving() does
- update filter,
- bind socket.
But, binding socket can be done in when the socket is opened.
Let's remove device_monitor_enable_receiving() and bind the socket in
device_monitor_new_full().
The struct itself is generic, and can be used for other ID.
Let's rename it to more generic one.
No functional change, just refactoring and preparation for later
commits.
Since Linux commit ddd1ad68826d ("net: bridge: Add netlink knobs for number
/ max learned FDB entries") [1] it is possible to limit to number of
dynamically learned fdb entries per bridge.
Add support to the systemd networkctl for the netlink bridge attributes
IFLA_BR_FDB_MAX_LEARNED and IFLA_BR_FDB_N_LEARNED.
[1] https://lore.kernel.org/all/20231016-fdb_limit-v5-0-32cddff87758@avm.de/
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
Since Linux commit ddd1ad68826d ("net: bridge: Add netlink knobs for number
/ max learned FDB entries") [1] it is possible to limit to number of
dynamically learned fdb entries per bridge.
Add support to the systemd netdev bridge for the new netlink attribute
IFLA_BR_FDB_MAX_LEARNED.
[1] https://lore.kernel.org/all/20231016-fdb_limit-v5-0-32cddff87758@avm.de/
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
This is a lot of stuff, and sometimes quite wild, let's turn this into
its own header.
All stuff color-related that just generates sequences is now in
ansi-color.h (no .c file!), and everything more complex that
probes/ineracts with terminals remains in termina-util.[ch]
This is a common case, and nothing noteworthy at all. For example, if we
establish an enumerator for listing all devices tagged by some tag, then
the per-tag dir is not going to exist if there are currently no devices
tagged that way, but that's a really common case, and doesn't really
deserve any mention, not even at debug level.
Daan De Meyer
Adrian Vovk
Yu Watanabe
Luca Boccassi
David Tardon
Gregor Herburger
Lennart Poettering
Mike Yuan