t/op/getppid.t fails under docker/travis #15727
Comments
From @kentfredricCreated by @kentfredricRecently all my travis targets for Perl Tests started failing t/op/getppid.t Even tests suites that had previously passed without fault started failing t/op/getppid ... 1..8 Initial diagnosis suggests docker is doing something where those processes Perl Info |
From @tonycozOn Mon, 21 Nov 2016 06:21:00 -0800, kentfredric@gmail.com wrote:
If you use something like: https://github.com/phusion/baseimage-docker/blob/rel-0.9.16/image/bin/my_init as the init process for your container, do the tests pass? Possibly related: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ http://blog.dscpl.com.au/2015/12/issues-with-running-as-pid-1-in-docker.html Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @kentfredricOn Mon, 21 Nov 2016 16:24:20 -0800, tonyc wrote:
Not able to comment on that as I don't believe I can usurp |
From @eserteDana Mon, 21 Nov 2016 17:10:30 -0800, kentfredric reče:
The problem is that the travis build/test script does not run at all below the init process. The process tree in a travis-ci container while running the failing getppid.t test looks roughly like this: PID PGID SID TTY TIME CMD Unlike in a traditional Unix system, there's not only one process tree, but three: a traditional init process with some standard daemons, the travis-ci build/test script (with bash as the root process), and the forked orphaned perl process, which is calling getppid() (recognizable by the additional "ps" process which I added to the getppid.t test). The problem seems to be that orphaned processes only started in the init tree would be adopted by the init process. In the other tree this is not done by the container's init process, but by a process outside the linux container. Maybe we can call this an "incognito adoption". Now what's getppid() returning in this case --- the parent process is outside the container? http://man7.org/linux/man-pages/man7/pid_namespaces.7.html says: "Calls to getppid(2) for such processes return 0." Consequence is that in such an environment the test should even allow 0 as the new parent: cmp_ok ($second, '>=', 0, "New parent of orphaned $which grandchild") Maybe accepting 0 should be done only on linux systems, and only if a container was detected. A possible check (adapted from http://stackoverflow.com/a/20012536/2332415) could look like this: sub is_container { For non-container systems the check could still be $second >= 1. BTW, to reproduce the issue in a docker system just make getppid.t use Test::More, copy it to the docker container and run docker exec -it name_of_container perl getppid.t In contrast, running the docker container normally with "docker run -it ... bash" and "perl getppid.t" inside would give a successful test run. |
From @eserteDana Sat, 25 Mar 2017 13:25:44 -0700, slaven@rezic.de reče:
Attached a possible patch for this issue. |
From @eserte0001-fix-t-op-getppid.t-in-linux-containers-RT-130143.patchFrom 544cccf5d9ad9ad99fa8750f0d912740e61b944d Mon Sep 17 00:00:00 2001
From: Slaven Rezic <slaven@rezic.de>
Date: Sat, 25 Mar 2017 21:39:15 +0100
Subject: [PATCH] fix t/op/getppid.t in linux containers (RT #130143)
Allow getppid() to return 0 if the test is running within a linux
container. From "man 2 getppid":
If the caller's parent is in a different PID namespace (see
pid_namespaces(7)), getppid() returns 0.
---
t/op/getppid.t | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/t/op/getppid.t b/t/op/getppid.t
index 11e0f64..3565525 100644
--- a/t/op/getppid.t
+++ b/t/op/getppid.t
@@ -35,7 +35,8 @@ sub fork_and_retrieve {
unless my ($how, $first, $second) = /^([a-z]+),(\d+),(\d+)\z/;
cmp_ok ($first, '>=', 1, "Parent of $which grandchild");
my $message = "grandchild waited until '$how'";
- cmp_ok ($second, '>=', 1, "New parent of orphaned $which grandchild")
+ my $min_getppid_result = is_linux_container() ? 0 : 1;
+ cmp_ok ($second, '>=', $min_getppid_result, "New parent of orphaned $which grandchild")
? note ($message) : diag ($message);
SKIP: {
@@ -104,6 +105,19 @@ sub fork_and_retrieve {
}
}
+sub is_linux_container {
+ my $is_linux_container = 0;
+ if ($^O eq 'linux' && open my $fh, '<', '/proc/1/cgroup') {
+ while(<$fh>) {
+ if (m{^\d+:pids:(.*)} && $1 ne '/init.scope') {
+ $is_linux_container = 1;
+ last;
+ }
+ }
+ }
+ $is_linux_container;
+}
+
my $first = fork_and_retrieve("first");
my $second = fork_and_retrieve("second");
SKIP: {
--
2.1.4
|
|
@atoomic - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release yesterday of Perl 5.28.0, this and 185 other issues have been Perl 5.28.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#130143 (status was 'resolved')
Searchable as RT130143$
The text was updated successfully, but these errors were encountered: