This exposes NM_VERSION as number (contrary to the "Version", which is a
string). That is in particular useful, because the number can be
compared with <> due to the encoding of the version.
While at it, don't make it a single number. Expose an array of numbers,
where the following numbers are a bitfield of capabilities.
Note that before commit 3c67a1ec5e ('cli: remove version check against
NM'), we used to parse the "Version" string to detect the version. As
such, the information that "VersionInfo" exposes now, was already
(somewhat) available, you just had to parse the string. The main benefit of
"VersionInfo" is that it can expose capabilities (patched behavior) in
in a lightweight bitfield. To include the numerical version there is
just useful on top.
Currently no additional capabilities are exposed. The idea is of course
to have a place in the future, where we can expose additional
capabilities. Adding a capability flag is most useful for behavior that we
backport to older branches. Otherwise, we could just check the daemon version
alone. But since we only add "VersionInfo" property only now, we cannot backport
any capability further than this, because the "VersionInfo" property itself
won't be backported. As such, this will only be useful in the future by having
a place where we can add (and backport) capabilities.
Note that there is some overlap with the existing "Capability" property
and NMCapability enum. The difference is that adding a capability via "VersionInfo"
is only one bit, and thus cheaper. Most importantly, having it cheaper means
the downsides of adding a capability flag is significantly removed. In
practice, we could live without capabilities for a long time, so they
must be very cheap for them to be worth to add. Another difference might be,
that we will want that the VersionInfo is about compile time defaults (e.g.
a certain patch/behavior that is in or not), while NM_CAPABILITY_TEAM depends on
whether the team plugin is loaded at runtime.
The warning "-Wcast-align=strict" seems useful and will be enabled
next. Fix places that currently cause the warning by using the
new macro NM_CAST_ALIGN(). This macro also nm_assert()s that the alignment
is correct.
Support managing the loopback interface through NM as the users want to
set the proper mtu for loopback interface when forwarding the packets.
Additionally, the IP addresses, DNS, route and routing rules are also
allowed to configure for the loopback connection profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=2060905
In case the D-Bus interfaces start dropping off (typically all off them go
one by one when the object is being deleted), don't reset all the properties.
In particular, keep most properties around, only tear down "o" and "ao",
so that the object dependencies get torn down, but we still get enough
properties around to identify what the dead object was its heyday.
One example of where this is not good is when the device-removed signal
is emmitted, the device no longer has the ifname:
$ nmcli monitor
<quit NetworkManager>
(null): device removed
(null): device removed
...
Fix up the doc comment so that the gir data gets that right.
Fixes: 90d0ae0faf ('libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly')
Add a fire-and-forget function to wait for shutdown to be complete.
It's not entirely trivial to ensure all resources of NMClient are
cleaned up. That matters only if NMClient uses a temporary GMainContext
that the user wants to release while the application continues. For
example, to do some short-lived operations an a worker thread. It's
not trivial also because glib provides no convenient API to integrate
a GMainContext in another GMainContext. We have that code as
nm_utils_g_main_context_create_integrate_source(), so add a helper
function to allow the user to do this.
The function allows to omit the callback, in which case the caller
wouldn't know when shutdown is complete. That would still be useful
however, when integrating the client's context into the caller's
context, so that the client's context gets automatically iterated
until completion.
The following test script will run out of file descriptors,
when wait_shutdown() is not used:
#!/bin/python
import gi
gi.require_version("NM", "1.0")
from gi.repository import NM, GLib
for i in range(1200):
print(f">>>{i}")
ctx = GLib.MainContext()
ctx.push_thread_default()
nmc = NM.Client.new()
ctx.pop_thread_default()
def cb(unused, result, i):
try:
NM.Client.wait_shutdown_finish(result)
except Exception:
# cannot happen
assert False
else:
print(f">>>>> {i} complete")
nmc.wait_shutdown(True, None, cb, i)
while GLib.MainContext.default().iteration(False):
pass
When using async initialization with GAsyncInitable, the user usually can
only know that initialization is complete by passing a callback.
In simple cases, that can be cumbersome.
Also expose a flag that allows to poll that information.
Reuse the existing NM_CLIENT_INSTANCE_FLAGS for that. There is an
ugliness here, that suddenly there are instance flags that cannot be
set, but are still returned by the getter. But as this is a relatively
obscure feature, it seems more lightweight to implement it this way
(instead of adding a separate property and getter function).
It was documented to be an optional parameter. That is also in line
with g_dbus_connection_call(), which is essentially wrapped by nm_client_dbus_call().
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
libnm-client-impl/nm-client.c:8398: warning: multi-line since docs found
libnm-client-impl/nm-device-macvlan.c:115: warning: multi-line since docs found
libnm-client-impl/nm-device-vxlan.c:540: warning: multi-line since docs found
libnm-client-impl/nm-device-vxlan.c:92: warning: multi-line since docs found
libnm-core-impl/nm-setting-ethtool.c:41: warning: multi-line since docs found
libnm-core-impl/nm-setting-ip-config.c:2475: warning: multi-line since docs found
libnm-core-impl/nm-setting-ip-config.c:2504: warning: multi-line since docs found
The typedefs in nm-types.h confuse gtkdoc-scan. It generates a
libnm-sections.txt file like this:
<SECTION>
<FILE>nm-types</FILE>
<TITLE>NMDeviceOvs</TITLE>
NMAccessPoint
NMActiveConnection
NMCheckpoint
NMClient
NMDevice
...
Note the wrongly picked title and, more importantly, the object types in
a bogus section. This in turn makes gtkdoc-mkdb fail to include the
property and signal documentation in appropriate sections.
Without nm-types.h, we need to mind the header dependencies. This means
that we need to order the headers that define types before the ones that
use them. Also, we need to break the depencency loops in few palces.
g_idle_add() uses G_PRIORITY_DEFAULT_IDLE priority. Most of the time we don't
care much about the priority.
But at the places that this patch changes, I think that using
G_PRIORITY_DEFAULT_IDLE (and following g_idle_add()) is more correct. The
reason for this is not very strong, except that it's probably the better
choice. And the old choice was made because I didn't realize that
g_idle_add() uses another default priority. Hence, the old choice was not
for good reasons either.
NMClient is strongly tied to the GMainContext with which it was created.
Several operations must only be called from within the context. There
was an assertion for that.
However, creating (and init_async()) should be allowed to call not
from within the GMainContext. So if the current context has no owner
(is not acquired), then it's also OK.
Fix the assertion for that.
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
When cloud-init job (metadata service crawler) starts, it sends the
SIGTERM signal to nm-cloud-setup and force the nm-cloud-setup to
restart, however, because the error is not initialized as NULL in
`_init_start_cancelled_cb()` before it is set, nm-cloud-setup will hit
a dumped core.
TO fix it, initialize the error as NULL in `_init_start_cancelled_cb()`.
https://bugzilla.redhat.com/show_bug.cgi?id=2027674
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
Backtrace:
#0 g_logv (log_domain=0x7f833a872071 "GLib", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../glib/gmessages.c:1413
#1 0x00007f833a81f043 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at ../glib/gmessages.c:1451
#2 0x00007f833ab97230 in nm_utils_error_set_cancelled (is_disposing=<optimized out>, instance_name=<optimized out>, error=0x7ffff79cb980) at src/libnm-glib-aux/nm-shared-utils.c:2599
#3 nm_utils_error_set_cancelled (is_disposing=0, instance_name=0x0, error=0x7ffff79cb980) at src/libnm-glib-aux/nm-shared-utils.c:2590
#4 _init_start_cancelled_cb (cancellable=<optimized out>, user_data=0x5640ca292150) at src/libnm-client-impl/nm-client.c:7324
#5 _init_start_cancelled_cb (cancellable=<optimized out>, user_data=0x5640ca292150) at src/libnm-client-impl/nm-client.c:7307
#6 0x00007f833a93094a in _g_closure_invoke_va (param_types=0x0, n_params=<optimized out>, args=0x7ffff79cbb40, instance=0x5640ca267020, return_value=0x0, closure=0x5640ca29d430)
at ../gobject/gclosure.c:873
#7 g_signal_emit_valist (instance=0x5640ca267020, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffff79cbb40) at ../gobject/gsignal.c:3406
#8 0x00007f833a930a93 in g_signal_emit (instance=instance@entry=0x5640ca267020, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3553
#9 0x00007f833a9a6475 in g_cancellable_cancel (cancellable=0x5640ca267020) at ../gio/gcancellable.c:513
#10 g_cancellable_cancel (cancellable=0x5640ca267020) at ../gio/gcancellable.c:487
#11 0x00005640ca1a8bd4 in sigterm_handler (user_data=0x5640ca267020) at src/nm-cloud-setup/main.c:599
#12 0x00007f833a819d4f in g_main_dispatch (context=0x5640ca268ef0) at ../glib/gmain.c:3337
#13 g_main_context_dispatch (context=0x5640ca268ef0) at ../glib/gmain.c:4055
#14 0x00007f833a86e608 in g_main_context_iterate.constprop.0 (context=0x5640ca268ef0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4131
#15 0x00007f833a819463 in g_main_loop_run (loop=0x5640ca24fdb0) at ../glib/gmain.c:4329
#16 0x00005640ca1a6d04 in nmc_client_new_waitsync (cancellable=0x5640ca267020, out_nmc=0x7ffff79cbfa0, error=0x7ffff79cbf98, first_property_name=0x5640ca1b11db "instance-flags",
first_property_name=0x5640ca1b11db "instance-flags") at src/libnm-client-aux-extern/nm-libnm-aux.c:129
#17 0x00005640ca1a3863 in main (argc=1, argv=<optimized out>) at src/nm-cloud-setup/main.c:639
When NMClient gets destroyed, it unrefs all NMObject. We need to unbreak
cycles then, and the property getters must return NULL. In particular,
for "o" type properties (NMLDBusPropertyO), this was not done correctly.
For example, calling nm_device_get_active_connection() while/after
destroying the NMClient can give a dangling pointer and assertion
failure. This will also be covered by test_activate_virtual(). Probably
a similar issue can happen, when a D-Bus object gets removed (without
destroying NMClient altogether).
The fix is that nml_dbus_property_o_clear() needs to clear "nmobj". That
is correct, because the pointer is no longer valid and should not be there.
And the unit test shows that in fact a pointer is left there, and
clearing it fixes it.
That was different from an earlier attempt to fix this (in commit 62b2aa85e8
('Revert "libnm: fix dangling pointer in public API while destructing NMClient"')),
where clearing the pointer at a different place broke things. That
attempt was wrong, because nml_dbus_property_o_notify_changed() needs to be the
one that sets/clears nmobj field during a regular update. But the case
here is not a regular update, nml_dbus_property_o_clear() happens during
unregister/cleanup, and then we need to clear the pointer.
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
https://bugzilla.redhat.com/show_bug.cgi?id=2039331https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/896
See-also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1064https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1075
This breaks test @nmcli_monitor. With this patch, `nmcli monitor` no
longer prints "There's no primary connection". Need to investigate why.
For now, revert the patch.
This reverts commit 2afecaf908.
While (and after) NMClient gets destroyed, nm_device_get_active_connection()
gives a dangling pointer. That can lead to a crash. This probably
affects all NMLDBusPropertyO type properties.
It's not clear how to fix that best. Usually, NMClient does updates in
two phases, first it processes the D-Bus events and tracks internal
data, then it emits all GObject signals and notifications.
When an object gets removed from the NMClient cache, then the second
phase is not fully processed, because the object is already removed
from the cache. Thus, the property was not properly cleared leaving
a dangling pointer.
A simple fix is to always clear the pointer during the first phase. Note that
effectively we do the same also for NMLDBusPropertyAO (by clearing the
"pr_ao->arr"), so at least this is consistent.
Somehow it seems that we should make sure that the "second" phase gets
full processed in this case too. But it's complicated, and it's not
clear how to do that. So this solution seems fine.
https://bugzilla.redhat.com/show_bug.cgi?id=2039331https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/896
We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.
So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.
As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).
The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as
Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)
[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
Currently a NML_DBUS_META_PROPERTY_INIT_FCN() property does not have
'extra' field available. In order to be able to call
'nml_dbus_property_ao_notify()' from the callback, the 'extra' field
must be available.
The patch is also dropping 'use_notify_update_prop' field as it only
existed to differentiate the union.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
The nm_ip_address_dup() and nm_ip_route_dup() symbols were exposed in
libnm 1.32 and then backported to 1.30.8.
Export it also with version @libnm_1_30_8; this allows a program build
against libnm 1.30.8 to keep working with later versions of the library.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
The nm_setting_ip_config_get_required_timeout() symbol was introduced
in libnm 1.32.4 and then backported to 1.30.8.
Export it also with version @libnm_1_30_8; this allows a program built
against libnm 1.30.8 to keep working with later versions of the
library.
Due to this, `nmcli connection load` would also not print a warning
about failure to load obviously bogus files:
$ nmcli connection load /bogus
Note that load is also used to unload files, so if the file name is a
possibly valid name for a non-existing file, there is no failure. For
example, we get no warning for
$ nmcli connection load /etc/NetworkManager/system-connections/bogus
Even if currently no such file is loaded, then the operation would still
silently succeed, instead of succeeding the first time only. That is because
load should be idempotent.
[thaller@redhat.com: rewrote commit message]
Fixes: 4af6219226 ('libnm: implement nm_client_load_connections_async() by using GDBusConnection directly')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/794https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/979
