linux/meta-virtualization.git - Mirror of git.yoctoproject.org/meta-virtualization

	Commit message (Collapse)	Author	Age	Files	Lines
*	runc: uprev to 1.0.0-rc5	Bruce Ashfield	2018-04-02	1	-19/+17
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	Uprev both variants of runc to v1.0.0-rc5. We drop patches that have made it into the upstream runc, and we also refresh the context of of two others. The docker and opencontainers variants are virtually identical, but we keep the two variants for now to protect against any future forks in the support. The runc-docker SRCREV comes from the docker-ce 18.04 logged commit, while runc-opencontainers is updated to the tip of the master branch. Runtime tested with docker on x86-64. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
*	runc-docker: Allow "run start ..." to daemonize with $SIGUSR1_PARENT_PID	Jason Wessel	2017-12-11	1	-0/+131
	The runc-docker has all the code in it to properly run a stop hook if you use it in the foreground. It doesn't work in the back ground because there is no way for a golang application to fork a child exit out of the parent process because all the golang threads stay with the parent. This patch has three parts that happen ONLY when $SIGUSR1_PARENT_PID is set. 1) At the point where runc start would normally exit, it closes stdin/stdout/stderr so it would be possible to daemonize "runc start ...". 2) The code to send a SIGUSR1 to the parent process was added. The idea being that a parent process would simply exit at that point because it was blocking until runc performed everything it was required to perform. 3) The code was copied which performs the normal the signal handling block which is used for the foreground operation of runc. -- More information -- When you use "runc run " it is running in the "foreground", in the sense it takes over your existing terminal. The runc-docker doesn't have a way to start it with "runc run&" where you can send it to the background and have everything work. With this commit, it does allow you to do that and have all the stop hooks fire at the time what ever runc started exits. Lets take a quick look at what "runc run" does today: * Starts a whole pile of threads * Sets up all name spaces * Starts child process for container and leaves it paused at image activation * runs start hooks * executes "continue" for container process * waits for container app to exit * executes stop hooks Now lets look at "runc create/start" does today: runc create * Starts a whole pile of threads * Sets up all name spaces * Starts child process for container and leaves it paused at image activation * exits -- [ NOTE: this is our problem! ] runc start * runs start hooks * executes "continue" for continue process At this point when the container app exits nothing is waiting for it to run any kind of hooks. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>