IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
That's not necessary. Moreover, if the socket units are stopped in
`setUpModule()`, then there exists a short timespan that we cannot call
`udevadm control`, as the control socket may not be opened yet.
If we run whole tests, then the first test is
NetworkctlTests.test_altname, and it calls `udevadm control` in `setUp()`.
Hence, the test may fail.
Fixes https://github.com/systemd/systemd-centos-ci/pull/512#issuecomment-1191591008.
Several DHCP client tests change the system timezone.
Let's save the current timezone at the beginning, and restore it with
the saved value at the end.
- introduce several helper functions
- do not list unit files, but remove the runtime unit directory in
tearDown().
- do not list used interfaces, but remove all interfaces previously not
exists in tearDown().
- save routes and routing policy rules before running tests, and flush
unnecessary routes and rules in each tearDown() calls.
- drop many time.sleep() calls.
- call tearDown() after each sub tests.
- shorten code.
- several coding style fixes.
- etc, etc...
Hopefully, this improves performance of the test.
`global` is needed only when assigning a new value to the global
variable; it's not necessary when modifying a mutable object (in our
case we just append items to the global list).
Otherwise, this easily trigger another exception:
```
======================================================================
ERROR: test_erspan_tunnel_v0 (__main__.NetworkdNetDevTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./test/test-network/systemd-networkd-tests.py", line 686, in wait_online
check_output(*args, env=env)
File "./test/test-network/systemd-networkd-tests.py", line 65, in check_output
return subprocess.check_output(command, universal_newlines=True, **kwargs).rstrip()
File "/usr/lib64/python3.6/subprocess.py", line 356, in check_output
**kwargs).stdout
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/usr/lib/systemd/systemd-networkd-wait-online', '--timeout=20s', '--interface=erspan99:routable', '--interface=erspan98:routable', '--interface=dummy98:degraded']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./test/test-network/systemd-networkd-tests.py", line 1808, in test_erspan_tunnel_v0
self.wait_online(['erspan99:routable', 'erspan98:routable', 'dummy98:degraded'])
File "./test/test-network/systemd-networkd-tests.py", line 689, in wait_online
output = check_output(*networkctl_cmd, '-n', '0', 'status', link.split(':')[0], env=env)
File "./test/test-network/systemd-networkd-tests.py", line 65, in check_output
return subprocess.check_output(command, universal_newlines=True, **kwargs).rstrip()
File "/usr/lib64/python3.6/subprocess.py", line 356, in check_output
**kwargs).stdout
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/usr/bin/networkctl', '-n', '0', 'status', 'erspan99']' returned non-zero exit status 1.
```
Not sure when the issue was fixed.
- kernel-3.10 on CentOS 7 has the issue,
- kernel-4.18 on CentOS 8 works fine.
Note, the workaround dropped by the commit is not incomplete:
with an old kernel which has the issue, all non-prefix routes are
configured on the specified route table, but the prefix route is
configured on the main table. That should not work for most cases,
hence, the workaround is mostly meaningless.
There is no reason networkd refuses that. Especially, when multiple
downstream interfaces are connected to the same network, it is natural to
assign the same subnet prefix to them.
Prompted by #22571.
