FTBFS: tests failures on [armhf,mips,mips64el,mipsel]

[onlyjob]

1.1.2 currently FTBFS on

• armhf
• mips
• mips64el
• mipsel

(and some other architectures) due to test failures.

Interestingly 1.0.3 used to built successfully on those architectures...

[asottile]

I believe this is a duplicate of #106

[chriskuehl]

Also #105. I'll get these fixed, thanks for the report!

[chriskuehl]

I think these should be fixed except for the kfreebsd builds, where dumb-init isn't working at all.

I'll try to debug kfreebsd soon. It's not super surprising as we've never tested or tried to support anything but the Linux kernel, but I'm certainly open to supporting it if we can.

@onlyjob can you check if this fixed the build for those other architectures? I don't have an easy way to test on those platforms.

[onlyjob]

Thanks. :)
Unfortunately I have no access to most of those architectures. I'll upload new release (once it is ready) and we'll see how it goes from build logs. I should have an old mips VM somewhere but right now I have no time to revive it... Sorry.

[chriskuehl]

@onlyjob I've released 1.1.3 which should have test fixes for those platforms, plus working support for FreeBSD (tested on the kfreebsd jessie port, anyway).

[onlyjob]

1.1.3 now FTBFS on x86_64 (a.k.a. amd64) in pbuilder:

tests/child_processes_test.py FFFF.................... 
tests/cli_test.py ...................................................................... 
tests/exit_status_test.py ................................................ 
tests/proxies_signals_test.py FFFFFFFFFFFFFFFFFFFFFFFFFF 
tests/shell_background_test.py FFFF 
tests/tty_test.py . 

Many processes like dumb-init /usr/bin/python -m testing.print_signals (and others) are left behind:

        ├─4*[dumb-init───sh─┬─2*[tail]]
        │                   └─2*[yes]]
        ├─30*[dumb-init───python]

I did not look deep into the problem but many tail processes are actively using CPU so clearly something unexpected is happening...

[chriskuehl]

That is really weird, this has passed several times on our own CI (Circle + internal Jenkins) and locally. All of this is amd64.

I'll look into this, thanks.

[chriskuehl]

Ah, I was finally able to reproduce this. The good news is that the binary itself seems to be fine (so we didn't make a broken release or anything), but the tests fail on Debian stretch for me with an error like this:

    def child_pids(pid):
        """Return a list of direct child PIDs for the given PID."""
        children = set()
        for p in LocalPath('/proc').listdir():
            stat = p.join('stat')
            if stat.isfile():
                stat = stat.open().read()
                m = re.match('^\d+ \([^\)]+\) [a-zA-Z] (\d+) ', stat)
>               assert m, stat
E               AssertionError: 2127 ((sd-pam)) S 2125 2125 2125 0 -1 1077936448 23 0 0 0 0 0 0 0 20 0 1 0 3443 80334848 476 18446744073709551615 1 1 0 0 0 0 0 4096 0 0 0 0 17 3 0 0 0 0 0 0 0 0 0 0 0 0 0

testing/__init__.py:57: AssertionError

This is because we changed the tests to stop using Linux-specific /proc features so that the tests would pass on FreeBSD. Looks like the way we're parsing the /proc/*/stat files is not totally correct and fails in some cases, though. Will fix this, thanks!

[chriskuehl]

@onlyjob the fix is merged, can you see if the build succeeds now? I confirmed it does on stretch for me.

Since this is a test-only change we don't plan to issue a new release.

[chriskuehl]

Looks like 1.2.0 has built successfully on these architectures: https://buildd.debian.org/status/package.php?p=dumb-init&suite=stretch

Thanks again @onlyjob!