[systemd-bugs] [Bug 87732] nspawn catches kill signal only when using jenkins

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=87732

--- Comment #8 from Lennart Poettering <lennart at poettering.net> ---
(In reply to Wulf C. Krueger from comment #7)
> (In reply to Lennart Poettering from comment #6)
> > Hmm, what is stdin/stdout/stderr connected to when this happens?
> 
> From
> https://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build:
> 
> "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 comment #1. 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20150211/8bef0ceb/attachment.html>