Two minor testsuite fixes

[SirPhuttel]

Patch 1 fixes for unexpected output from dbus-daemon on Fedora Rawhide, patch 2 fixes a spurious error when calling test_linux.sh a second time.

[s1061123]

Looks good to me, thanks!
/lgtm

[squeed]

@SirPhuttel this is failing lint, can you fix that?

[SirPhuttel]

Hmm. I wasn't able to find a failure cause in the CI logs. Maybe something to improve? It seems the system creates a tarball with logs, but it's not made available?
Anyway, I figured I could run 'gofmt' myself and it suggested to use a tab instead of whitespace for the continued line in firewall_firewalld_test.go. Let's see if CI is happy now. :)

[SirPhuttel]

That failing test is odd. I can't reproduce it locally, maybe a one-off? The error seems unrelated to the testsuite fixes at least. Also, it's odd how iptables chain "removal" happening in portmap's teardown() implicitly creates a chain. IIUC, the code does 'iptables -N foo && iptables -X foo' ten times in parallel? In the same netns?

[squeed]

That test failure is due to a go-iptables bug I need to get around to fixing. It doesn't detect all the right error codes, I think.

[SirPhuttel]

That test failure is due to a go-iptables bug I need to get around to fixing. It doesn't detect all the right error codes, I think.

I didn't have a close look at go-iptables, but I think it would benefit from more "transactional behaviour", e.g. instead of iptables -N foo && iptables -X foo it should be possible to iptables-restore --noflush <<< "*filter\n:foo - [0:0]\n-X foo\nCOMMIT" i.e., be less racey and save an extra execve() doing so.

[squeed]

I didn't have a close look at go-iptables, but I think it would benefit from more "transactional behaviour"

Indeed it should. Honestly, it needs a rewrite (or just to be killed); it's a random survivor from the old CoreOS days.

[SirPhuttel]

I didn't have a close look at go-iptables, but I think it would benefit from more "transactional behaviour"

Indeed it should. Honestly, it needs a rewrite (or just to be killed); it's a random survivor from the old CoreOS days.

Yes, just adding a "batch mode" means introducing a new API anyway. Luckily go-nft has this already, so if users migrate the fork'n'exec overhead will go away.