Compile srcdir into test-dispatcher-envp rather than passing it on the
command-line, to make it easier to run by hand, and so we can use
automake's TESTS support.
Reorganize some code in preparation for the GDBus port. (Most of the
diff is actually just reindentation.)
This also makes explicit something that was probably a bug;
IP4_NUM_ROUTES is always set, even if it's "0" (while the same is not
true of IP6_NUM_ROUTES). (This behavior is preserved for
compatibility.)
The rewrite mistakenly used nm_connection_add_setting() rather than
_nm_connection_add_setting(), causing it to emit the "changed" signal
while the connection was only partially rebuilt.
If two code paths try to asynchronously create the same object at the
same time (eg, because it shows up in two different properties), we
are supposed to deal with that. But at some point a race condition
appeared where we could end up returning a partially-initialized
object for one of the properties in the async case. Fix that.
Also add comments to both the sync and async cases explaining why they
work the way they do.
If _nm_object_create() hit an error, it would return the
(half-initialized) object anyway. If _nm_object_create_async() hit an
error, it would return NULL, but leak the half-initialized object. Fix
both cases.
libnm-util's connection deserializing/copying/replacing functions have
odd semantics where sometimes they both modify a connection AND return
an error. libnm-core tried to improve things by guaranteeing that the
connection would not be modified if the new settings were invalid, but
this ended up breaking a bunch of places that needed to be able to
work with invalid connections. So re-fix the functions by reverting
back to the old semantics, but having return values that clearly
distinguish whether the connection was modified or not.
For comparison:
- nm_connection_new_from_hash() / nm_simple_connection_new_from_dbus():
- libnm-util: returns a valid connection or NULL.
- OLD libnm-core: returned a valid connection or NULL.
- NEW libnm-core: returns a valid connection or NULL.
- nm_connection_duplicate() / nm_simple_connection_new_clone():
- libnm-util: always succeeds, whether or not the connection is
valid.
- OLD libnm-core: returned a valid connection or NULL
- NEW libnm-core: always succeeds, whether or not the connection
is valid.
- nm_connection_replace_settings_from_connection():
- libnm-util: always replaces the settings, but returns FALSE if
the connection is now invalid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: always replaces the settings, and has no
return value. (The modified connection is valid if and only if
the replaced-from connection was valid; just like with the
libnm-util version.)
- nm_connection_replace_settings():
- libnm-util: returns TRUE if the new settings are valid, or
FALSE if either (a) the new settings could not be deserialized
and the connection is unchanged, or (b) the new settings were
deserialized, and the connection was updated, but is now not
valid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: returns TRUE if the connection was updated
(whether or not it is valid), or FALSE if the new settings
could not be deserialized and the connection is unchanged.
It needs to be possible to deserialize a connection hash into an
invalid NMConnection; in particular, AddAndActivateConnection()
explicitly allows this.
Previously, the SetFunc and NotSetFunc passed to
_nm_setting_class_override_property() could return a verification
error immediately, but this functionality has to go away if we're
going to be able to deserialize invalid connections.
That functionality was only used in the handling of invalid virtual
interface names; reorganize how that code works so that
NMSettingConnection does all of the verification itself. (The code to
make sure that it returned the "correct" error domain in that case
turned out to be irrelevant, since the setting error domains don't get
serialized over D-Bus correctly anyway.)
Empty array-valued properties should return a 0-length array from
get_property(), but should also accept NULL as equivalent to a
0-length array from set_property().
UINT is just 32bit, truncating the GType on 64-bit platforms. We do already use
cast to SIZE, which is as wide as a pointer, when we need a GType in another
place (nmtui); let's do it here as well.
Broken by [0bc1b5138] core: add support for internal device factories
https://bugzilla.gnome.org/show_bug.cgi?id=736780
DHCP client may be killed by SIGPIPE when attempting to write to a broken pipe.
This can be observed, for example, when journald is restarted.
Fix that by redirecting both stdout and stderr to /dev/null. The client logs
into syslog anyway. When NetworkManager is run with '--debug' we duplicate
syslog to stderr, so the messages goes to terminal as well.
Testcase:
- start a NetworkManager service by systemd
- activate an DHCP ethernet connection
- sudo systemctl restart systemd-journald.service
- reactive the ethernet connection (nmcli con up <my-eth>)
- DHCP client is killed by SIGPIPE right after its startup:
<info> (enp0s25): DHCPv4 client pid 13959 exited with status -1
<warn> DHCP client died abnormally
Another possible fix would be ignoring SIGPIPE in the DHCP client as it is not
useful in most cases. E.g. systemd ignores SIGPIPE for its services, by
default:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=353e12c2f4a9e96a47eb80b80d2ffb7bc1d44a1bhttps://bugzilla.gnome.org/show_bug.cgi?id=735962
gcc's linker does not add constructors from object files to the main
executable if they are built into a convenience library and then the
library is linked to the executable, unless something outside of the
object file with the constructor references a symbol from the object
file.
http://osdir.com/ml/libtool-gnu/2011-06/msg00003.html
"Yes, when convenience libraries are used to create a shared library, all the
objects are included in the output, when the output is an application they are
used like a normal archive library.
Either use them to create a shared library or, if creating an application,
don't use them, use the objects instead."
Further patches will remove all references to the NMDevice subclasses
from nm-manager.c, and have each NMDevice subclass register itself
with a factory through a constructor. But due to the above issue,
we need to somehow ensure the constructor in each nm-device-*.c file
gets added to the executable. This is accomplished by explicitly
linking each NMDevice subclass' object file into the main executable.
(Note that we cannot use -Wl,-whole-archive here because libtool only
supports this option for linking a convenience library to a shared
library, but not to an executable, and will actively prevent using
-whole-archive in LDFLAGS)
In preparation for internal device types exposing factories too, it's
easier to have the device type that the factory creates be returned
by the factory object instead of the plugin, because internal device
types don't have plugins.
This requires that we create the factory objects earlier, which
further requires that any operations that trigger signals must be
moved out of each factory's construction path to a separate start()
function.
Instead of creating it in NMSettings, where we must use
NM_IS_DEVICE_ETHERNET() (not NM_DEVICE_TYPE_ETHERNET because various generic
devices masquerade as NM_DEVICE_TYPE_ETHERNET too), push knowledge
of which device types create default wired connections into the device
types themselves. This solves a problem with testcases where
libNetworkManager.a (which testcases link to) requires the symbol
nm_type_device_ethernet().
