<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - nspawn catches kill signal only when using jenkins" href="https://bugs.freedesktop.org/show_bug.cgi?id=87732#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - nspawn catches kill signal only when using jenkins" href="https://bugs.freedesktop.org/show_bug.cgi?id=87732">bug 87732</a> from <a class="email" href="mailto:lennart@poettering.net" title="Lennart Poettering <lennart@poettering.net>"> Lennart Poettering</a> <pre>(In reply to Wulf C. Krueger from <a href="show_bug.cgi?id=87732#c7">comment #7</a>) > (In reply to Lennart Poettering from <a href="show_bug.cgi?id=87732#c6">comment #6</a>) > > Hmm, what is stdin/stdout/stderr connected to when this happens? > > From > <a href="https://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build">https://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build</a>: > > "Jenkins and the child process are connected by three pipes > (stdin/stdout/stderr.) This allows Jenkins to capture the output from the > child process. Since the child process may write a lot of data to the pipe > and quit immediately after that, Jenkins needs to make sure that it drained > the pipes before it considers the build to be over. Jenkins does this by > waiting for EOF." Hmm, indeed, so I figure we need provide some better compat with pipes here... > > Currently, this needs to be a tty, since nspawn provides it as a tty > > internally, too. > > This changed between 217 and 218 as pointed out in <a href="show_bug.cgi?id=87732#c1">comment #1</a>. So I'm not > quite sure why... Well, we previously left the container running until both the input and output pipes got EOF. This had the effect that running nspawn within a shell pipeline would make it hang unconditionally. So we changed it to exit on one EOF already, which now terminates it too early for your usecase. It's basically, that we break one usecase by making another work... I general I think the current behaviour is slightly nicer than the old one, since "hanging" is really weird... I figure to solve this for good we need to implement: a) when we detect that nspawn is invoked with a non-tty as stdin/stdout, then don't connect stdin/stdout of the commands invoked in the container with a pty, but also with a pair of pipes. b) teach systemd, when run inside a container like this to not close stdout for each status update, but keep it continiously open. (currently we close/reopen /dev/console for each status update on the console, since the kernel SAK logic will otherwise kill us...) Change a) should make things work for you. Change b) would then allow running systemd itself in a pipeline inside of nspawn.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>