[Pkg-swan-devel] Bug#926479: Interesting ..

[Christian Ehrhardt]

Hi,
that is very interesting, thanks for pulling me in.

Since the same tests ran in Ubuntu for quite a while I checked it, but
it looks good across the board [1] and since you posted an amd64 fail
I checked that for Xenial [2] and Bionic [3] which both look non flaky
to me on our infrastructure at least.

However that was just a statement for the overall status. They seem to
be flaky for you, so let us take a look why.

To reproduce I did:
$ autopkgtest-build-lxd images:debian/sid/amd64
$ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest
--test-name=daemon --no-built-binarie
s --apt-upgrade --shell-fail strongswan_5.7.2-1.dsc -- lxd
images:debian/sid/amd64

That really gave me in Debian the failing services ?! why would that
be different?

The command above gives you a login into the just failed test
environment and there really is no pid for the daemon. This also does
not resolve over time.

The reason is that normally a started service would look like:
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
  Loaded: loaded (/lib/systemd/system/strongswan.service; enabled;
vendor preset: enabled)
  Active: active (running) since Sun 2019-04-07 12:05:59 UTC; 2min 20s ago
Main PID: 14806 (starter)
   Tasks: 18 (limit: 547)
  Memory: 4.9M
  CGroup: /system.slice/strongswan.service
          ├─14806 /usr/lib/ipsec/starter --daemon charon --nofork
          └─14845 /usr/lib/ipsec/charon

Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading aa
certificates from '/etc/
Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading
ocsp signer certificates fr
Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading
attribute certificates from
Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading
crls from '/etc/ipsec.d/crl
Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading
secrets from '/etc/ipsec.se
Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[LIB] loaded
plugins: charon aes rc2 sha2
Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[LIB] dropped
capabilities, running as ui
Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[JOB] spawning 16
worker threads
Apr 07 12:05:59 disco-checklvm-pass ipsec[14806]: charon (14845)
started after 40 ms
Apr 07 12:05:59 disco-checklvm-pass ipsec_starter[14806]: charon
(14845) started after 40 ms

But on the Debian test it is like:
systemctl status strongswan
.service
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
  Loaded: loaded (/lib/systemd/system/strongswan.service; enabled;
vendor preset: enabled)
  Active: inactive (dead) since Sun 2019-04-07 12:00:56 UTC; 8min ago
Main PID: 1120 (code=exited, status=0/SUCCESS)

Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: 00[CFG] expanding
file expression '/var/li
b/strongswan/ipsec.secrets.inc' failed
Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: 00[LIB] failed to
load 2 critical plugin f
eatures
Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: 00[DMN]
initialization failed - aborting c
haron
Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: charon has quit:
initialization failed
Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: charon refused to be started
Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec_starter[1120]: charon has
quit: initialization fa
iled
Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: ipsec starter stopped
Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec_starter[1120]: charon
refused to be started
Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec_starter[1120]: ipsec
starter stopped
Apr 07 12:00:56 autopkgtest-lxd-gstxpo systemd[1]: strongswan.service:
Succeeded.

The other tests work in the container environment, but the daemon
itself needs a VM to load modules and fails in containers.
The reason it is flaky might be that it runs on VMs sometimes and on
Containers in the other cases.

The fix for that would be simple, how about:

diff --git a/debian/tests/control b/debian/tests/control
index eb9e20463c..b6afafd29d 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,7 @@
-Tests: daemon admin-strongswan-charon admin-strongswan-starter plugins
+Tests: admin-strongswan-charon admin-strongswan-starter plugins
Depends: strongswan, libstrongswan-standard-plugins,
libstrongswan-extra-plugins, libcharon-e
xtra-plugins, strongswan-pki, strongswan-scepclient
Restrictions: needs-root isolation-container allow-stderr
+
+Tests: daemon
+Depends: strongswan-starter
+Restrictions: needs-root isolation-machine allow-stderr


I have no Debian VM that supports autopkgtest, maybe you could upload
that to experimental or the QA team could otherwise help to verify the
suggestion.
Or - if you want - you can take the change as is, as it should be really safe.


[1]: http://autopkgtest.ubuntu.com/packages/strongswan
[2]: http://autopkgtest.ubuntu.com/packages/strongswan/xenial/amd64
[3]: http://autopkgtest.ubuntu.com/packages/strongswan/bionic/amd64

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd