DEP8 error on armhf
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| libseccomp (Ubuntu) |
Fix Released
|
Undecided
|
Andreas Hasenack | ||
Bug Description
Version 2.5.4-2 introduced this change in d/t/control:
libseccomp (2.5.4-2) unstable; urgency=medium
* Fix watch file. (Closes: #1050659)
* Dynamically skip autopkgtests when the test runner already applies seccomp
restrictions.
- Drop isolation-machine restriction.
-Restrictions: isolation-machine, allow-stderr
+Restrictions: skippable, allow-stderr
This made the test run in Ubuntu again on armhf, where we use a lxd container (it wasn't running previously). This change is relying on this check in d/t/common:
if ! grep -q -E '^Seccomp:
echo "Skipping autpkgptest as the test environment already applies a seccomp filter"
exit 77
fi
In Debian, where they also use containers, the testsuite-
541s live
541s ./regression: line 253: cd: /tmp/autopkgtes
10468s autopkgtest [01:49:37]: kill with SIGTERM did not work sending SIGKILL
Related branches
- git-ubuntu bot: Approve
- Bryce Harrington (community): Approve
- Canonical Server Reporter: Pending requested
-
Diff: 37 lines (+18/-0)2 files modifieddebian/changelog (+7/-0)
debian/tests/testsuite-live-python3 (+11/-0)
| Changed in libseccomp (Ubuntu): | |
| assignee: | nobody → Andreas Hasenack (ahasenack) |
| status: | New → In Progress |
| description: | updated |
| description: | updated |
| description: | updated |
| tags: | added: server-todo |
| Andreas Hasenack (ahasenack) wrote | #1 |
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in libseccomp (Ubuntu): | |
| status: | In Progress → Fix Released |
In the ubuntu armhf DEP8 infrastructure, this is what /proc/self/status looks like when that failing test starts (I added a "cat /proc/self/status" to debug):
Name: cat
Umask: 0002
State: R (running)
Tgid: 1105
Ngid: 0
Pid: 1105
PPid: 1102
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 64
Groups: 4 24 27 30 115 1000
NStgid: 1105
NSpid: 1105
NSpgid: 1092
NSsid: 1092
VmPeak: 4164 kB
VmSize: 4164 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 644 kB
VmRSS: 644 kB
RssAnon: 64 kB
RssFile: 580 kB
RssShmem: 0 kB
VmData: 328 kB
VmStk: 132 kB
VmExe: 24 kB
VmLib: 1188 kB
VmPTE: 36 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 0
THP_enabled: 1
Threads: 1
SigQ: 0/63405
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Speculation_
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_
nonvoluntary_
Seccomp: 0
Specifically, "Seccomp: 0" tells us that there is no seccomp filtering applied. Therefore, the test runs.
When I launch an armhf container on my pi4, even a privileged one, I get "Seccomp: 2" and "Seccomp_filters: 1", so there is some filtering applied and the test is skipped.
In the debian armhf DEP8 infrastructure, "Seccomp: 0" is not present in /proc/self/status (I don't know the full contents) when the test starts, so the "grep" check makes it exit with status 77 and the test is skipped.
I don't know how to further troubleshoot this, since it only happens in the ubuntu DEP8 infrastructure, and using it for step by step debugging will take a long time.