This bug resulted in spurious lines with "--pretty --mode tabular",
whenever nmc_print() was called with multiple rows.
Currently, the only case where this was visible was with:
$ nmcli --pretty general permissions
(note that "--mode tabular" is the default).
Fixes: 16299e5ac0
nm_ppp_manager_stop() wants to ensure that the pppd process is really
gone. For that it uses nm_utils_kill_child_async() to first send
SIGTERM, and sending SIGKILL after a timeout.
Later, we want to fix shutdown of NetworkManager to iterate the mainloop
during shutdown, so that such operations are still handled. However, we
can only delay shutdown for a certain time. After a timeout (NM_SHUTDOWN_TIMEOUT_MS
plus NM_SHUTDOWN_TIMEOUT_MS_GRACE) we really have to give up and
terminate.
That means, the right amount of time between sending SIGTERM and SIGKILL
is exactly NM_SHUTDOWN_TIMEOUT_MS. Hopefully that is of course
sufficient in the first place. If not, send SIGKILL afterwards, and give
a bit more time (NM_SHUTDOWN_TIMEOUT_MS_GRACE) to reap the child.
And if all this time is still not enough, something is really odd and we
abort waiting, with a warning in the logfile.
Since we don't properly handle shutdown yet, the description above is
not really true. But with this patch, we fix it from point of view of
NMPPPManager.
Previously, there were two functions nm_ppp_manager_stop_sync() and
nm_ppp_manager_stop_async().
However, stop-sync() would still kill the process asynchronously (with a
2 seconds timeout before sending SIGKILL).
On the other hand, stop-async() did pretty much the same thing as
sync-code, except also using the GAsyncResult.
Merge the two functions. Stopping the instance for the most part can be
done entirely synchrnous. The only thing that is asynchronous, is
to wait for the process to terminate. For that, add a new callback
argument to nm_ppp_manager_stop(). This replaces the GAsyncResult
pattern.
Also, always ensure that NetworkManager runs the mainloop at least as
long until the process really terminated. Currently we don't get that
right, and during shutdown we just stop iterating the mainloop. However,
fix this from point of view of NMPPPManager and register a wait-object,
that later will correctly delay shutdown.
Also, NMDeviceWwan cared to wait (asynchronously) until pppd really
terminated. Keep that functionality. nm_ppp_manager_stop() returns
a handle that can be used to cancel the asynchrounous request and invoke
the callback right away. However note, that even when cancelling the
request, the wait-object that prevents shutdown of NetworkManager is
kept around, so that we can be sure to properly clean up.
We usually structure our code in a (pseudo) object oriented way.
It makes sense to call the variable for the target object "self",
it is more familiar and usually done.
- add callback arguments to _ppp_kill(). Although most callers don't
care, it makes it more obvious that this kills the process
asynchronously.
- the call to nm_utils_kill_child_async() is complicated, with many
arguments. Only call it from one place, and re-use the simpler wrapper
function _ppp_kill() everywhere.
Eventually we should do a coordinated shutdown when NetworkManager exits.
That is a large work, ensuring that all asynchronous actions are cancellable
(in time), and that we wait for all pending operations to complete.
Add a function nm_shutdown_register_watchdog(), so that objects can register
themselves, to block shutdown until they are destroyed. It's not yet used,
because actually iterating the mainloop during shutdown can only be done,
once the code is prepared to be ready for that. But we already need the
function, so that we can refactor individual parts of the code, in preparation
of using it in the future.
Before:
$ nmcli c modify Dukkha ipv4.ignore no
Error: invalid property 'ignore': 'ignore' is ambiguous (ignore-auto-routes x (null)).
After:
$ nmcli c modify Dukkha ipv4.ignore no
Error: invalid property 'ignore': 'ignore' is ambiguous (ignore-auto-routes x ignore-auto-dns).
call_nmcli_l() would test for 3 languages: 'C', 'de', and 'pl'. There
is no fundamental difference between 'de' and 'pl', so there is no need
to test for two languages.
Activate the same profile on two devices. Arguably, real NetworkManager
(currently) does not allow that. But the D-Bus API is fine with
having multiple ActiveConnections for one SettingsConnection.
So, also the client should do something sensible.
Also, later we will add wildcard support to NetworkManager, which means
that a profile can be active multiple times (simultaneously).
This is purely for (manual) printf debugging. Hence, it is unused in the commited code.
The point is, to add printf statements to nmcli or libnm, like
if (getenv ("MY_HACK1")) { ...
and trigger it from test-client.py via
self.call_nmcli(..., extra_env = { 'MY_HACK1': '1' } )
- don't use GSList as intermediate data type to construct
the environment, especially when all we want is to get
a strv array at the end. This reverts the order of elements
compared to previously.
- add and use helper methods _items_add_*() which assert against sensible
input.
- merge IPv4 and IPv6 implementations for creating the environment.
https://github.com/NetworkManager/NetworkManager/pull/112
libnm-util/crypto_gnutls.c: In function crypto_encrypt:
libnm-util/crypto_gnutls.c:245:8: error: variable salt_len set but not used [-Werror=unused-but-set-variable]
gsize salt_len;
^~~~~~~~
See-also: 312c72f761
glib 2.56's g_steal_pointer() won't tolerate a function pointer in place
of a gpointer.
CC src/src_libNetworkManager_la-nm-active-connection.lo
src/nm-active-connection.c:1017:17: error: pointer type mismatch
('NMActiveConnectionAuthResultFunc' (aka 'void (*)(struct _NMActiveConnection *,
int, const char *, void *)') and 'gpointer' (aka 'void *'))
[-Werror,-Wpointer-type-mismatch]
result_func = g_steal_pointer (&priv->auth.result_func);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmem.h:200:6: note: expanded from macro 'g_steal_pointer'
(0 ? (*(pp)) : (g_steal_pointer) (pp))
^ ~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
There's just a single spot we use it that way, so it's perhaps better to
work around the warning instead of disabling it.
Avoids an annoying warning in Fedora:
|DEPRECATION WARNING: python2 invoked with /usr/bin/python.
Use /usr/bin/python3 or /usr/bin/python2
/usr/bin/python will be removed or switched to Python 3 in the future.
Also allows the user to override the Python version that's actually
used.
Previously, the callbacks would return gl.mainloop.quit(), which is None
and thus the source got removed already. The later GLib.source_remove()
would thus use an invalid source-id.
Fix that, by no removing the source id from the callback.
Fixes: b1ff82eba5
Instead of exporting exported-objects during construction, export
them right before we register them (for example, in case of device
instances, before we add the device to the manager's device list).
Likewise, when removing the object from the list, always explicitly
unexport them.
Without explicitly unexporting the objects, they can also not be
removed, because object-manage and D-Bus library keep references
to them.
Instead of registering a __get_props() function which constructs the
entire hash anew each time, register a props dictionary. This dictionary
is used as cache for the properies.
In most cases, we don't need to additionally cache the properties
outside the props dictionary. Also, add _dbus_property_set() which
sets the property and emits the notification.
Also, cleanup the property names by giving them a PRP_ prefix.
The reasons are:
- I want to locate all implmenetations of the get_fcn() handler. By
consistently using this macro, you can just grep for the macro and
find them all.
- all implementations should follow the same style. This macro
enforces the same names for arguments and avoids copy&paste.
- if we are going to add or change an argument, it becomes easier.
That's because we can easily identify all implementation and can
change arguments in one place.
These helper function will be needed in the next commit to be earlier.
Helper functions like these, that operate solely on trival types (in
this case, converting an enum to a string), make generally sense to have
at the beginning of the source file. Because they themself have few/no
dependencies and are rather trivial and self contained.
Functions like nmc_find_connection() and nmc_find_active_connection()
can easily find multiple matching results. For example, the
"connection.id" in NetworkManager is not enforced to be unique,
so if the user adds multiple connections with the same name,
they should be all selected.
The previous API had a @pos argument, that allowed to iterate over
the results. Change that, to return all matches in a GPtrArray.
Also, extend connection-show and other places, to anticipate that
a connection might be active multiple times in any moment.
