Comment 3 for bug 1576914

Build https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu23/+build/9668581 has been cancelled, and the failure shown in the log there is:

not ok 13 - ensure remainder of log written when file deleted with uid 0
 wrong value for output, got unexpected (nil)
 at tests/test_log.c:868 (test_log_new).
/bin/bash: line 5: 40392 Aborted ${dir}$tst
FAIL: test_log

This was not the same failure that I saw, but possibly related.

After adjusting settings in the chroot, libnih still fails its testsuite with wholly uninteresting 'string' problems related to terminal sizes that are almost certainly unrelated and specific to the test environment.

And upstart now fails locally with a variety of apparently flaky tests. E.g.:

test: Failed to spawn test main process: unable to execute: No such file or directory
ok 67 - with no such file, no shell and console log
ok 68 - with debug enabled
ok 69 - ensure sane fds with no console
ok 70 - ensure sane fds with console log
not ok 71 - ensure multi process output logged
        wrong value for stat (filename, &statbuf), expected 0 got -1
        at tests/test_job_process.c:4803 (test_spawn).
/bin/bash: line 5: 51948 Aborted (core dumped) ${dir}$tst
FAIL: test_job_process

or, in another run:

not ok 147 - ensure re-exec does not disrupt umask
 wrong value for ok, expected 1 got 0
 at tests/test_initctl.c:11385 (test_reexec).
/bin/bash: line 5: 31440 Aborted (core dumped) ${dir}$tst
FAIL: test_initctl

or:

not ok 136 - with child exit notification before child setup success notification
        wrong value for timed_waitpid (pid, 5), expected 63974 got 0
        at tests/test_job_process.c:8957 (test_handler).
/bin/bash: line 5: 63192 Aborted (core dumped) ${dir}$tst
FAIL: test_job_process

There's repetition in the failing tests; a completely clean run is elusive.

And I've just noticed the last good build of upstart on s390x, <https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu21/+build/9278268>, was more than a month after the package was uploaded. So the successful build is the result of a retry of a failed build, which means there's nothing to say that a kernel change between 4.4.0-18 and 4.4.0-21 has anything to do with this.