>> If we want to have a back-channel, we'd need a socket, which makes >> just >> doing echo RUNNING > /dev/lxc-notify impossible, you'd need a >> special >> program for that. Having the template scripts dump an additional >> script >> or upstart job or systemd unit file or whatever in the container >> when >> creating it seems a lot easier than having to use a special program. > > FYI, the systemd team actually want to be able to expose a full > socket > from the container to the host, so that the host systemd/systemctl > cmd > can directly communicate with the container's systemd. So I don't > think > that /dev/lxc-notify would be useful for systemd.
First of all, you have to separate two things - I mentioned systemd here in the sense that when the system reaches default.target, /dev/lxc-notify should be pinged so that the lxc state now changes from BOOTING to RUNNING. What you are talking about is a systemctl on the outside of the container affecting the inside. I wanted to solve the first problem, where /dev/lxc-notify is useful anyway, with or without systemd. The use case you are describing is a bit more complicated. You want to expose a socket outside the container that is listened to by a program inside the container. The problem here is that if you want to bind-mount it before the pivot_root call, this will not work since bind() for a socket will fail if the file already exists. But as soon as you are already in the container, if systemd actually does listen to a socket somewhere, you'll have a hard time bind-mounting it back to the outside, How do you bridge the mount namespace? Obviously, if the container's filesystem is mounted on the host anyway, you don't have a problem, since you don't need to take care about the namespace; but what if the lxc config specifies a block device that is then only mounted inside the container's namespace? That being said, if we actually implement /dev/lxc-notify (or however one wants to call it, perhaps /run/lxc-host-interface?) as a socket with an extensible protocol, it would be possible not only to have a command that tells lxc to open a socket on the host and pass the fd back through the connection, then systemd on the inside would be in posession of a socket that listens on the outside and that an outside systemctl could affect. So my proposal with the modifications suggested by Stéphane would actually be able also solve your use case. However, first I'd like to have the basic version just for status updates (because that is a useful feature anyway, independently of the init system) in order to keep it simple - and once that is done, one may think about how/whether to extend this to include other use cases that are more specialized. ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
