Coverity is unpredictable and, according to a notification I received
yeserday, it will be upgraded on June 17. During the upgrade
it might be offline for 3 days, af far as I understand. Anyway, Travis
stops as soon as a stage fails so it makes sense to put stages that
are likely to fail at the end so that the others have a chance to
do what they are supposed to do.
Jeka Pats [Tue, 11 Jun 2019 06:25:45 +0000 (09:25 +0300)]
Continuous Fuzzing Integration with Fuzzit
includes two travis ci steps:
1) Every pull-request/push all fuzzing targets will do a quick
sanity run on the generated corpus and crashes (via Fuzzit)
2) On a daily basis the fuzzing targets will be compiled (from
master) and will and their respectible fuzzing job on Fuzzit
will be updated to the new binary.
networkd-tests.py: remove some java-style boilerplate
A class was used to put some utility functions under a namespace. But then this
namespace was inherited into classes, so the namespace split was undone. Let's
just define those functions in the module namespace.
(The Utilities class with a few functions still remain, because of the
unittest-style self.assert* craziness.)
networkd-tests.py: add helpers to common subprocess call patterns
For normal shell calls, python syntax is quite verbose. We don't need to punish
ourselves like that. In some places we would fork a shell to do argument splitting
for us. We know that our arguments can be safely split on whitespace, so let's do
that ourselves in all cases, without forking a shell.
We also expect command output to be valid text, so let's always set
universal_newlines=True.
This makes things shorter and easier to read. Development is also easier because
it's possible to paste many of the commands directly to/from a shell.
Yu Watanabe [Wed, 5 Jun 2019 15:42:05 +0000 (00:42 +0900)]
network: check stored object is euivalent to what we want to remove
When object A is stored in Manager::rules and B is in ::rules_foreign,
and compare function for the object cannot distinguish them,
then freeing A causes B to be removed from rules_foreign or vice versa.
udevadm trigger: log errors and return first failure
When udevadm trigger is called, the list of devices to trigger is always
generated through enumeration, and devices can come and go, so we should not
treat -ENOENT as a failure. But other types of failure should be logged.
It seems they were logged until baa30fbc2c04b23209d0b8fb3c86cd15ef9ea81a.
Also, return the first error. (I'm not sure if there are other failure modes
which we want to ignore. If they are, they'll need to be whitelisted like
-ENOENT.).
We'd get a warning on every nspawn invocation:
dev-hugepages.mount: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling.
(This warning is only shown for the first unit using IP firewalling.)
Before the previous commit, I'd generally get a warning about systemd-udev.service, even though that service is
not started in containers. But are still many other units which that declare a
firewall, which is currently unsupported in containers. Let's stop warning
about this.
The warning is still emitted e.g. if legacy cgroups are used. This is something
that can be configured, so it makes more sense to emit the warning.
Move warning about unsupported BPF firewall right before the firewall would be created
There's no need to warn about the firewall when parsing, because the unit might
not be started at all. Let's warn only when we're actually preparing to start
the firewall.
This changes behaviour:
- the warning is printed just once for all unit types, and not once
for normal units and once for transient units.
- on repeat warnings, the message is not printed at all. There's already
detailed debug info from bpf_firewall_compile(), so we don't need to repeat
ourselves.
- when we are not root, let's say precisely that, not "lack of necessary privileges"
and "the local system does not support BPF/cgroup firewalling".
It was impossible to view systemd.nspawn(5), because systemd-nspawn(1) was matched
also, and happened to be earlier in the list. The solution in this patch is pretty
crude, but is should be enough for our purposes, since we don't have any regexp
special characters in man page names except for the dot.
busctl: always prefix bus error message with local string
The message we get from the bus can be pretty bare-bones, and the user might be
confused which operation failed. Since we don't control the other side, let's
prefix the remote message with an informative prefix.
sd-bus: improve bus error message for uknown properties
"Unknown interface or property." →
"Unknown interface org.freedesktop.network1.Link or property BitRates."
(I don't think the quotes are necessary. Dbus names have pretty strict rules.)
networkctl: log quietly if we fail to get bit rates
If we query older networked, they will be missing. This is not an error.
Also, make the error more informative, because the bus error itself might
be just "Unknown interface or property" which is not enough to understand
what is going on.