Yu Watanabe [Thu, 18 Feb 2021 08:25:51 +0000 (17:25 +0900)]
sd-device: move comment about NULL value
It is not intuitive, and I do not know why the function behave so.
But let's keep that behavior for compatibility, as such behavior
may be already used explicitly by callers.
man: split out sd_bus_set_fd() man page from sd_bus_get_fd()
sd_bus_get_fd() and related calls are useful for integrating a bus
connection into arbitrary event loops. But sd_bus_set_fd() is quite a
different beast, it's for using D-Bus over pre-initialized sockets or
pairs of fifos or stuff, i.e. very advanced stuff.
Let's split this man page in two, in order not to confuse things
needlessly.
And while we are at it, let's slightly extend the documentation.
systemctl: don't search in the full argv[0] for the invocation name
argv[0] might be prefixed by a path, and we shouldn't get confused by
that. Hence provide a simple helper call that abstracts the checking
away, which we can use everywhere, and expose the same behaviour, even
if argv[0] is not set.
(While we are at it, port all other multi-call binaries over to the new
helper, too)
See https://wiki.gnome.org/HowDoI/DBusApplicationLaunching and
https://wiki.gnome.org/Initiatives/GnomeGoals/DBusActivatable for a description
of this key:
> Instead of the typical UNIX-style fork()/exec() approach to process creation,
> launching an application is done by sending a D-Bus message to the well-known
> name of that application, causing a D-Bus activation.
>
> Starting processes with D-Bus activation ensures that each application gets
> started in its own pristine environment, as a direct descendent of the
> session -- not in the environment of whatever its parent happened to be. This
> is important for ensuring the app ends up in the correct cgroup, for example.
So this motivation is not important for us: we launch stuff ourselves better.
This fixes warnings during boot:
systemd-xdg-autostart-generator[2274]: /etc/xdg/autostart/org.freedesktop.problems.applet.desktop:92: Unknown key name 'DBusActivatable' in section 'Desktop Entry', ignoring.
Yu Watanabe [Fri, 5 Feb 2021 01:09:12 +0000 (10:09 +0900)]
network: nexthop: update ID of nexthop created without specifiying ID
Otherwise, nexthop_configure() -> nexthop_add() creates NextHop object
without ID in link->nexthop, and then, manager_rtnl_process_nexthop() ->
nexthop_add_foreign() also creates another NextHop object with ID in
link->nexthop_foreign.
Yu Watanabe [Wed, 17 Feb 2021 07:17:37 +0000 (16:17 +0900)]
network: warn when any positive boolean string is specified for IPMasquerade=
Previously, any positive boolean string for IPMasquerade= enables only IPv4
masquerade. The commit 48ed276647c754bfb3ed5c6c5af9404e073ffe54 adds
IPv6 masquerade support. However, only "yes" is handled as "ipv4", and other
positive boolean strings are handled as "both".
This makes all positive boolean strings considered as "ipv4", warn that they
are deprecated, and suggest to use "ipv4" or "both".
oomd: increase accuracy of SwapUsedLimit= to permyriads too
oomd.conf has two parameters with fractionals: SwapUsedLimit= and
DefaultMemoryPressureLimit=, but one accepts permyriads, the other only
percentages, for no apparent reason. One carries the "Percent" in the
name, the other doesn't.
Let's clean this up: always accept permyriads, and drop the suffix,
given that it is misleading.
I figure we should internally try to focus on scaling everything
relative to UINT32_MAX, and if that isn't in the cards at least 10000,
but never permille nor percent unless there's a really really good
reason for it (e.g. interface defined by someone else).
core: use our usual UINT32_MAX scaling for OOMD limits
So far OOMD limits used permyriads, as an upgrade from the original
percent.
The rest of our codebase typically scales stuff relative to UINT32_MAX.
Let's clean this up, an make sure this happens here too. This is
particularly relevant, as this is exposed in unit files and API, and
before we mark this stable we should get the APIs right.
parse-util: add format string macro for outputting permyriad
Let's define a set of macros for making output of permyriad values easy.
They are printed in pure ASCII, i.e. without the permille/permyriad
suffix, using just percent and two places after the dot.
util: add some helpers for converting percent/permille/permyriad to parts of 2^32-1
At various places we accept values scaled to the range 0…2^32-1 which
are exposed to the user as percentages/permille/permyriad. Let's add
some helper macros (actually: typesafe macro-like functions) that help
with converting our internal encoding to the external encodings.
benefits: some of the previous code rounded up, some down. let's always
round to nearest, to ensure that our conversions are reversible. Also,
check for overflows correctly.
This also adds a test that makes sure that for the full
percent/permille/permyriad ranges we can convert forth and back without
loss of accuracy.
percent-util: when parsing permyriads, permit percents too with 1 place after the dot
Previously, when parsing myriads, we'd support:
x% → percent, no places after the dot
x.yz% → percent, two places after the dot
x‰ → permille, no places after the dot
x.y‰ → permille, one place after the dot
x‱ → permyriad, no places after the dot
Given that we now have a parser for permyriads, let's use it everywhere
for greater accuracy. This means wherever we previously supported % and
‰, we now also support ‱.
udevadm: after validating action, use our internal string instead of optarg
This doesn't really change anything, but feels nicer, since it abstracts
away what device_action_from_string()/device_action_to_string() do
internally, and always uses a normalized action string (yes, there's no
ambiguity, but it's nice to stay abstract, maybe one day there is
ambiguity around this)
To make sd-device properly usable for all programs we need to provide an
API for the "action" field of an event, it's one of the most relevant
ones, and it was so far missing.
This also adds sd_device_get_seqnum(), which isn't that interesting,
except for generating pretty debug output, which we use it ourselves
for.
This also makes device_new_from_stat_rdev() public, as it is truly
useful, as we can see in our own uses of it, and I think is fairly
generic to show up in the public APIs.
Apparently, in our current public headers (i.e. those called sd-*.h) we
suffixed typedefs that we use as values with _t, but we didn't do this
for enum typedefs. Fix that while this stuff is not actually public yet.
With this scheme "value typedefs" now end systematically in _t, and
"object typedefs" (i.e. structures that are typically passed around via
pointers and not values) do not.
resolved: tweak how we calculate MTU for sending packets
Let's take all MTU info we possibly have into account, i.e. the one
reported via netlink, as before and the one the socket might now (from
PMTUD and such), clamped by our own ideas.
resolved: collect incoming fragment size when receiving UDP datagrams
We can later use this to adapt our announced EDNS buffer size in order
to avoid fragmentation to make the best of large datagrams while still
avoiding he security weaknesses of it.
I'm seeing the following with kernel-core-5.10.16-200.fc33.x86_64:
$ sudo SYSTEMD_LOG_LEVEL=debug build/systemd-rfkill
Reading struct rfkill_event: got 8 bytes.
A new rfkill device has been added with index 0 and type bluetooth.
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
rfkill0: Operating on rfkill device 'tpacpi_bluetooth_sw'.
Writing struct rfkill_event successful (8 of 9 bytes).
Loaded state '0' from /var/lib/systemd/rfkill/platform-thinkpad_acpi:bluetooth.
Reading struct rfkill_event: got 8 bytes.
A new rfkill device has been added with index 1 and type wwan.
rfkill1: Operating on rfkill device 'tpacpi_wwan_sw'.
Writing struct rfkill_event successful (8 of 9 bytes).
Loaded state '0' from /var/lib/systemd/rfkill/platform-thinkpad_acpi:wwan.
Reading struct rfkill_event: got 8 bytes.
A new rfkill device has been added with index 2 and type bluetooth.
rfkill2: Operating on rfkill device 'hci0'.
Writing struct rfkill_event successful (8 of 9 bytes).
Loaded state '0' from /var/lib/systemd/rfkill/pci-0000:00:14.0-usb-0:7:1.0:bluetooth.
Reading struct rfkill_event: got 8 bytes.
A new rfkill device has been added with index 3 and type wlan.
rfkill3: Operating on rfkill device 'phy0'.
Writing struct rfkill_event successful (8 of 9 bytes).
Loaded state '0' from /var/lib/systemd/rfkill/pci-0000:04:00.0:wlan.
All events read and idle, exiting.
We were expecting a read of exactly RFKILL_EVENT_SIZE_V1==8 bytes. But the
structure has 9 after [1].
/* we don't need the 'hard' variable but accept it */
if (count < RFKILL_EVENT_SIZE_V1 - 1)
return -EINVAL;
/*
* Copy as much data as we can accept into our 'ev' buffer,
* but tell userspace how much we've copied so it can determine
* our API version even in a write() call, if it cares.
*/
count = min(count, sizeof(ev));
if (copy_from_user(&ev, buf, count))
return -EFAULT;
... so it should accept the full size. I'm not sure what is going on here.
But we don't care about the extra fields, so let's accept a write as long as
it's at least RFKILL_EVENT_SIZE_V1.
Luca Boccassi [Fri, 12 Feb 2021 15:30:10 +0000 (15:30 +0000)]
os-util: allow missing VERSION_ID on the host
Rolling releases, like ArchLinux, do not set VERSION_ID in
their os-release files, so allow matching simply on ID if the host
does not provide anything.
projects / thirdparty / systemd.git / log
