The libnm cache types don't have public _new() functions.
However, such types can be easily created using g_object_new()
directly from user code.
Such a usage is not supported. Add an assertion that a valid
dbus-object is present.
I think NM_CACHED_QUARK_FCN() is better because:
- the implementation is in our hand, meaning it is clear that
putting a "static" before NM_CACHED_QUARK_FCN() is guaranteed to
work -- without relying on G_DEFINE_QUARK() to be defined in a way
that this works (in fact, we currently never do that and instead
make all functions non-static).
- it does not construct function names by appending "_quark".
Thus you can grep for the entire function name and finding
the place where it is implemented.
- same with the stings, where the new macro doesn't stringify the
argument, which is less surpising. Again, now you can grep
for the string including the double quoting.
(yes, I really use grep to understand the source-code)
The user can't do much about it and we can recover. This is a temporary
measure to avoid unnecessarily bothering the user.
(cherry picked from commit 7fec0755c9)
They indicate a server bug (a dangling path of an object that does not
exist). The best we can do probably is to just ignore them and warn.
Based-on-patch-by: Dan Williams <dcbw@redhat.com>
This speeds up the initial object tree load significantly. Also, it
reduces the object management complexity by shifting the duties to
GDBusObjectManager.
The lifetime of all NMObjects is now managed by the NMClient via the
object manager. The NMClient creates the NMObjects for GDBus objects,
triggers the initialization and serves as an object registry (replaces
the nm-cache).
The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
object creation, removal and property changes. It takes care of the
property changes so that we don't have to and lets us always see a
consistent object state. Thus at the time we learn of a new object we
already know its properties.
The NMObject unfortunately can't be made synchronously initializable as
the NMRemoteConnection's settings are not managed with standard
o.fd.DBus Properties and ObjectManager APIs and thus are not known to
the ObjectManager. Thus most of the asynchronous object property
changing code in nm-object.c is preserved. The objects notify the
properties that reference them of their initialization in from their
init_finish() methods, thus the asynchronously created objects are not
allowed to fail creation (or the dependees would wait forever). Not a
problem -- if a connection can't get its Settings, it's either invisible
or being removed (presumably we'd learn of the removal from the object
manager soon).
The NMObjects can't be created by the object manager itself, since we
can't determine the resulting object type in proxy_type() yet (we can't
tell from the name and can't access the interface list). Therefore the
GDBusObject is coupled with a NMObject later on.
Lastly, now that all the objects are managed by the object manager, the
NMRemoteSettings and NMManager go away when the daemon is stopped. The
complexity of dealing with calls to NMClient that would require any of
the resources that these objects manage (connection or device lists,
etc.) had to be moved to NMClient. The bright side is that his allows
for removal all of the daemon presence tracking from NMObject.
Don't let a later property update finish than the sooner one.
This wouldn't happen most of time, apart from a special case when the
latter update of a object array property is to an empty list.
In that case the latter update would complete sooner and when the
earlier update finishes the list would contain objects which are
supposed to be gone already.
Previously, when the load of an object failed and there were other
objects waiting for it, those objects would remain waiting
forever. Make them fail as well.
We don't want to update the properties until the objects referred are complete.
Otherwise the clients get confused. Very confused:
https://bugzilla.redhat.com/show_bug.cgi?id=1313866
We already delay the notification signals. Let's replace that with delaying the
actual ObjectCreatedData processing instead.
GError codes are only unique per domain, so logging the code without
also indicating the domain is not helpful. And anyway, if the error
messages are not distinctive enough to tell the whole story then we
should fix the error messages.
Based-on-patch-by: Dan Winship <danw@gnome.org>
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
Otherwise the uninitializeded objects could be prematurely signalled if their
paths are seen twice in quick succession. This happens when you have ethernet
hardware and add an ethernet connection -- it's immediatelly added to
AvialableConnections and the property reload signals the object addition
before the NMRemoteSettings's GetSettings() finishes:
# nmcli c add type ethernet autoconnect no ifname '*'
(process:4610): libnm-CRITICAL **: nm_connection_get_id: assertion 's_con != NULL' failed
Connection '(null)' ((null)) successfully added.
#
https://bugzilla.gnome.org/show_bug.cgi?id=754794
Otherwise the uninitializeded objects could be prematurely signalled if their
paths are seen twice in quick succession. This happens when you have ethernet
hardware and add an ethernet connection -- it's immediatelly added to
AvialableConnections and the property reload signals the object addition
before the NMRemoteSettings's GetSettings() finishes:
# nmcli c add type ethernet autoconnect no ifname '*'
(process:4610): libnm-CRITICAL **: nm_connection_get_id: assertion 's_con != NULL' failed
Connection '(null)' ((null)) successfully added.
#
https://bugzilla.gnome.org/show_bug.cgi?id=754794
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
When a new connection is activated and presently active connection goes away,
the active-connection-removed signal is not emitted for the old connection.
This is what happens:
1.) Initially, nm-manager::active-connections = [ActiveConnection/old]
2.) First PropertyChange is signalled for the new connection addition:
nm-manager::active-connections = [ActiveConnection/old,ActiveConnection/new]
This triggers load of ActiveConnection/new object.
3.) Another PropertyChange is signalled for the old connection removal:
nm-manager::active-connections = [ActiveConnection/new]
This removes the ActiveConnection/old object from
nm-manager::active-connections and enqueues active-connection-removed
signal. The signal is not emmitted as there's a reload from 2.) in progress.
4.) ActiveConnection/new reload finished
object_property_complete() compares
[ActiveConnection/old,ActiveConnection/new] from its odata to current
nm-manager::active-connections and incorrectly concludes that
ActiveConnection/old was just added and removes the enqueued
active-connection-removed signal.
This patch fixes the issue by remembering the original
nm-manager::active-connections property value at 2.).
[thaller@redhat.com: fixed an integer overflow and odata->array unreffing]
https://bugzilla.redhat.com/show_bug.cgi?id=1079353
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
"gettext (string)" (which will use the program's default domain, which
works fine for programs in the NetworkManager tree, but not for
external users). Likewise, we need to call bindtextdomain() so that
gettext can find the translations if the library is installed in a
different prefix from the program using it (and
bind_textdomain_codeset(), so it will know the translations are in
UTF-8 even if the locale isn't).
(The fact that no one noticed this was broken before is because the
libraries didn't really start returning useful translated strings much
until 0.9.10, and none of the out-of-tree clients have been updated to
actually show those strings to users yet.)
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Because internal objects do some processing/setup in the various
_added class signal handlers, they need to be emitted before
property change notifications. Otherwise it leads to situations
where external objects that listen to NMClient property changes
will be called before internal processing has been completed.
Specifically, NMRemoteSettings uses connection_added() to check
connection visibility and assign the new connection to one of
two internal arrays. If a client got a property notification
for NMClient::connections before NMRemoteSettings can process
the new connection, then nm_client_get_connections() will
return an empty array because NMRemoteSettings hasn't had the
chance to add the new connection to priv->visible yet, which
is done in NMRemoteSettings::connection_added().
Fixes:Beaker:NetworkManager_Test240_nmtui_general_realtime_refresh_edit_screen
Property notifications are queued during object initialization and
reloading, but the added/removed signals were emitted immediately
even before the object was fully initialized.
Additionally, depending on how long asynchronous initialization took,
the notifications could have been emitted before the object was
fully initialized as deferred_notify_cb() wasn't being suppressed
until all the properties were complete.
For synchronous intialization, signals could be emitted at various
times during initialization and not all of the object's properties
may be read. Furthermore property notifications were queued in an
idle handler, which breaks users that may not use a mainloop. All
signals and notifications should be emitted immediately after
initialization is complete for synchronous initialization.
To make things consistent and ensure that all signals and notifications
are emitted only when initialization is complete, queue signals for
deferred emission and only run notifications/signals when all the
object's properties have been read. For synchronous initialization,
emit all notifications and signals immediately after initialization
and not from an idle handler.
If the operation isn't canceled it returns an error, printing this:
/libnm/client-nm-running:
(/home/dcbw/Development/fdo/NetworkManager/libnm/tests/.libs/lt-test-nm-client:17983): libnm-WARNING **: updated_properties: error reading NMRemoteSettings properties: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
/bin/sh: line 5: 17983 Trace/breakpoint trap ./libnm-test-launch.sh ${dir}$tst
FAIL: test-nm-client
which screws up testcases because they don't expect this message.
And in this case, since libnm knows that NM is exiting and will
just clear out the properties anyway, it's useless to print the message.
It might simply mean that the object disappeared (which is perfectly fine):
(process:7680): libnm-WARNING **: Could not fetch property 'Vpn' of interface 'org.freedesktop.NetworkManager.Connection.Active' on /org/freedesktop/NetworkManager/ActiveConnection/151: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
https://bugzilla.gnome.org/show_bug.cgi?id=739255
This fixes the /libnm/client-nm-running test failure when a race condition is hit:
test-nm-client:10350): libnm-WARNING **: updated_properties:
error reading NMRemoteSettings properties:
GDBus.Error:org.freedesktop.DBus.Error.NoReply:
Message did not receive a reply (timeout by message bus)
What actually happens is that nm_running_changed_cb() calls GetAll() for a
NMRemoteSettings object when NM appears on the bus. If it disappears shortly
afterwards, another nm_running_changed_cb() is called which suppresses further
object updates, but the original GetAll() might not have finished yet and DBus
will generate a NoReply() response for it. We ought to ignore it.
Consolidate NMClientError and NMObjectError (such that there is now
only one libnm-API-specific error domain). In particular, merge
NM_CONNECTION_ERROR_CONNECTION_REMOVED with
NM_OBJECT_ERROR_OBJECT_CREATION_FAILURE as the new
NM_CONNECTION_ERROR_OBJECT_CREATION_FAILED.
Also make object_creation_failed() be a plain method rather than a
signal, since there's no reason for anyone to be connecting to it on
another object. And remove its GError argument because the subclass
can just create its own more-specific error.
NMActiveConnection:specific-object was renamed to
NMActiveConnection:specific-object-path in 677314c5, but it didn't
actually work, because of assumptions NMObject makes. Fix that.
3e5b3833 changed various libnm methods to return 0-length arrays
rather than NULL, and changed various other places to assume this
behavior. The guarantee that they didn't return NULL relied on the
assumption that all D-Bus properties would get initialized by NMObject
code before anyone could call their get methods.
However, this assumption was violated in the case where two objects
circularly referenced each other (eg, NMDevice and
NMActiveConnection). f9f9d297 attempted to fix this by slightly
changing the ordering of NMObjectCache operations, but it actually
ended up breaking things and causing infinite loops of object creation
in some cases.
There's no way to guarantee we never return partially-initialized
objects without heavily rewriting the object-creation code, so this
reverts most of f9f9d297 (leaving only the new comment in
_nm_object_create()). The crashes introduced by 3e5b3833 will no
longer happen because we've now fixed the classes to have initialized
their object arrays to non-NULL values even before they get the real
values.
Make enum- and flags-valued properties use GParamSpecEnum and
GParamSpecFlags, for better introspectability/bindability.
This requires no changes outside libnm-core/libnm since the expected
data size is still the same with g_object_get()/g_object_set(), and
GLib will internally convert between int/uint and enum/flags GValues
when using g_object_get_property()/g_object_set_property().
