[lxc-devel] [patch 00/17] Concentrate the commands in the lxc_start process

Daniel Lezcano dlezcano at fr.ibm.com
Wed Oct 7 08:28:31 UTC 2009


This patchset makes the 'start' to have a af_unix socket opened
and waiting for commands from the outside. That will help to solve
some problems and make the design cleaner.

 * some runtime files are stored in the /var/lib/lxc tree and can
   be not delete in case of failure. The lxc-stop commands check
   if the lock is taken in the /var/lib/lxc/mycontainer to check if
   the container is running and then read the 'init' file for getting
   the value of the first process of the pid namespace and kills it.
   The kill is asynchronous, so it is hard to synchronize the end of
   the container with the end of the stop. This error was reported by
   http://sourceforge.net/tracker/?func=detail&aid=2549465&group_id=163076&atid=826303

 * if we run the containers and the host crash or is poweroff, the
   state files are still there in the 'RUNNING' state, so if we do
   a 'lxc-info' that will display a wrong value.

Using the af_unix socket solves these problems:

 * we send a 'stop' command, the process supervising the container
   (aka 'start'), kills the processes of the container and returns
   on its mainloop without sending an answer to the sender of the
   stop command. When all the processes are dead the 'start' exits,
   closing automatically the socket. The 'stop' waiting for an answer
   has its connection closed, which is the correct behavior, and exits.
   Hence, the lxc-stop command returns when the lxc-start exits.

 * we store the state in the container handler structure instead in a file,
   and when a command 'info' is received, we returns this value to the caller.

These are the two first modifications done for replacing the current usage
of the files in /var/lib/lxc/* but this command socket will be used for
more features later.





More information about the lxc-devel mailing list