We encountered the following situation:
* nm-online (NetworkManager-wait-online.service) is started
* NetworkManager tries to configure network
* the first try of using dhclient fails with timeout for some reasons
* the second try of running dhclient completes successfully (NMs tries himself)
We get a working network, but it takes more that 30 seconds.
NetworkManager-wait-online.service fails, it may be a false negative
to checkers of network being online. It will also be a false positive signal
to start mounting network (CIFS, NFS etc.) shares, for example, because
they depend from network-online.target and network-online.target will become
reached right after NetworkManager-wait-online.service fails.
So, it makes sense to increase default timeout from 30 to 60 seconds.
@thaller wrote in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/237
that there may be cases where, for example, incorrectly set up bridges
or just network may lead to delays when booting the system.
Yes, but:
* if there is no possibility to start trying to connect the network, e.g. if all network interfaces,
managed by NetworkManager, are DOWN, NM will not try to connect network and "nm-online -s" will
exit with 0 without waiting (so, this will not prolong start up of workstations or servers
when ethernet cable is just not plugged in)
* an additional potential 30 seconds delay seems to be less harmful then a false positive to start
mounting network shares or doing abything else too eraly, when an additional wait for a few seconds
would have prevented those things from failing.
All things considered, it seems reasonable to increase this timeout from 30 seconds to 1 minute (60 seconds).
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/675
Rework update_system_hostname() to use the new properties from the
hostname setting.
In the default configuration where all the 3 boolean properties
hostname.{from-dhcp,from-dns,only-from-default} are true, the behavior
is the same as before.
When a new active connection is created, it gets added at the
beginning of manager's list. This means that the list contains most
recently activated connections first. Since the list is doubly-linked,
it is possible to efficiently iterate in both directions, so the order
of the list is mostly a matter of convention.
I think it is preferable to have oldest active connections at the
beginning of the list; let's reverse the order.
In most places where the list is iterated, the order doesn't
matter. Where it does, use the *_prev() variant to maintain the old
iteration order.
The following merge request in ModemManager introduces a more or less
common timeout value for the connection attempts in all plugin and
protocol implementations:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/391
The value chosen by default for the steps that may take long to
complete in a connection attempt is 180s, and 120s for the steps in
the disconnection path.
Until now, every different plugin or protocol had a different timeout
value, all of them <= 180s, and with that change in ModemManager, the
values are now aligned for all.
Note, though, that this does not mean that a connection attempt will
take always less than 180s, as there may be multiple other steps in
addition to the one that took the maximum timeout. The value chosen
for NetworkManager is a compromise between the new defaults from MM
and what the user would expect under e.g. very low quality conditions.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/678
In connection_removed we use the id.name that was being g_freed a few
lines further down.
Fixes: bea6c40367 ('wifi/iwd: handle forgetting connection profiles')
C casts unconditionally force the type, and as such they don't
necessarily improve type safety, but rather overcome restrictions
from the compiler when necessary.
Casting a void pointer is unnecessary (in C), it does not make the
code more readable nor more safe. In particular for g_object_new(),
which is known to return a void pointer of the right type.
Drop such casts.
sed 's/([A-Za-z_0-9]\+ *\* *) *g_object_new/g_object_new/g' $(git grep -l g_object_new) -i
./contrib/scripts/nm-code-format-container.sh
If an NMSettingsConnection with the VOLATILE or EXTENRAL flags is created
and passed to nm_manager_activate_connection, it's immediately scheduled
for deletion in an idle callback and will likely be deleted before the
authorization step in nm_manager_activate_connection finishes and the
connection will be aborted. This is because there's no
NMActiveConnection in priv->active_connection_lst_head referencing it
until _internal_activate_device(). Change
active_connection_find_by_connection to also look for connections in
priv->async_op_lst_head.
New _delete_volatile_connection_do() calls are added. Previously it
would be called when an active connection may have been removed from
priv->active_connection_lst_head, now also call it when an active
connection may have been removed from priv->async_op_lst_head without
being added to priv->active_connection_lst_head.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/671
The goal is to run most distros only manually. However, it would be nice
to avoid (manually) clicking twice to start the tests for one distro:
once for the container preparation, and once for the actual test.
Previously, the container prep part was set to manual and the actual
test automatic. It worked almost as desired, except that this leads
to the entire gitlab-ci pipeline be be in running state indefinitely.
To fix that, always run the container prep steps. If the container is
cached, this is supposed to be fast and cheap. Now only the actual tests
are marked as "manual".
It seems "pages" test does not get properly triggered, if only
t_fedora:33 completes. It should, because the other distros are
optional. Try to set "needs" to fix that.
We now install black by default via REQUIRED_PACKAGES script.
Thus, also when we build on Fedora 30, `make check` would run
python black. However, the formatting depends on the version
of python black, and the one in Fedora 30 is not right.
Skip all black tests during `make check`. We have a deicated
gitlab-ci test that runs black already (with the desired version
of black).
The checkpatch test tests the patches on the merg-request, as they
branch off from master (or one of the stable branches).
It thus need the full git history, but the git repository might be a
shallow clone. Fix it.
Certain parts of the code are entirely generated or must follow
a certain format that can be enforced by a tool. These invariants
must never fail:
- ci-fairy generate-template (check-ci-script)
- black python formatting
- clang-format C formatting
- msgfmt -vs
On the other hand, we also have a checkpatch script that checks
the current patch for common errors. These are heuristics and
only depend on the current patch (contrary to the previous type
that depend on the entire source tree).
Refactor the gitlab-ci tests:
- split "checkpatch" into "check-patch" and "check-tree".
- merge the "check-ci-script" test into "check-tree".
Now that the individual steps are no longer in .gitlab.yml but we
run a full shell script, clean it up to be better readable.
Also, we need to fail the script when any command fails.
"debian/REQUIRED_PACKAGES" is used by gitlab-ci to prepare the image. We require
"udev" package, if only to install "/usr/share/pkgconfig/udev.pc" to get the
udev directory.
Otherwise build fails with:
Run-time dependency udev found: NO (tried pkgconfig)
meson.build:371:2: ERROR: Dependency "udev" not found, tried pkgconfig
Before, ovsdb_call_method() has a long list of arguments
to account for all possible commands. That does not scale.
Instead, introduce a separate OvsdbMethodPayload type and
only add a macro to allow passing the right parameters.
The text should match the OvsdbCommand enum. If the enum
value is named OVSDB_ADD_INTERFACE, then we should print
"add-interface". Or alternatively, if you think spelling
out interface is too long, then the enum should be renamed.
I don't care, but name should correspond.
ovsdb sends monitor updates, with "new" and "old" values that indicate
whether this is an addition, and update, or a removal.
Since we also cache the entries, we might not agree with what ovsdb
says. E.g. if ovsdb says this is an update, but we didn't have the
interface in our cache, we should rather pretend that the interface
was added. Even if this possibly indicates some inconsistency between
what OVS says and what we have cached, we should make the best of it.
Rework the code. On update, we compare the result with our cache
and care less about the "new" / "old" values.
We will call the function directly as well. Lets aim to
get the types right.
Also the compiler would warn if the cast to (GDestroyNotify)
would be to a fundamtally different function signature.
GHashTable is optimized for data that has no separate value
pointer. We can use the OpenvswitchBridge structs as key themselves,
by having the id as first field of the structure and only use
g_hash_table_add().
Of course, in practice "mtu" is much smaller than 2^31, and
also is sizeof(int) >= sizeof(uint32_t) (on our systems). Hence,
this was correct. Still, it feels ugly to pass a unsigned integer
where not the entire range is covered.
- rename "id" to something more distinct: "call_id".
- consistently use guint64 type. We don't want nor need
to handle negative values. For CALL_ID_UNSPEC we can use
G_MAXUINT64.
- don't use "i" format string for the call id. That expects
an "int", so it's not clear how this was working correctly
previously. Also, "int" has a smaller range than our 64bits.
Use instead "json_int_t" and cast properly in the variadic
arguments of json_pack().
Also, never update the value to %NULL. If the current
message does not contain a UUID, keep the previous one.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
