[Lxc-users] regarding lxc "states" available to lxc-monitor or lxc-wait usage

[Vallevand, Mark K]

I'm not doing anything special with the container or the socket file.  The container is based on the Ubuntu template and I'm running a single program in the container.  The program will create its socket file according to its command line.  A program in the host looks for the socket file in the /var/lib/lxc/container/rootfs and uses it.  It works.

I'm using Ubuntu 12.04 LTS.


Regards.
Mark K Vallevand   Mark.Vallevand at Unisys.com
May you live in interesting times, may you come to the attention of important people and may all your wishes come true.
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

-----Original Message-----
From: Serge Hallyn [mailto:serge.hallyn at ubuntu.com] 
Sent: Sunday, May 12, 2013 11:33 PM
To: brian mullan
Cc: Vallevand, Mark K; LXC Users
Subject: Re: [Lxc-users] regarding lxc "states" available to lxc-monitor or lxc-wait usage

Quoting brian mullan (bmullan.mail at gmail.com):
> So given that a socket approach could work... would it make sense if there
> was some sort of standardized method employed for reading/writing etc.

Could work, but it's not pretty.  I'd suggest if you want to do this,
you bind mount the unix sock file using lxc.mount.entry into the
container.

Mark, where do you keep them?

> It would be beneficial if there was some sort of documented standard that
> people could use so everyone that develops an app for a container could
> report via lxc-monitor or lxc-wait a private-state that is understood
> or could be used by anyone?
> 
> 
> On Fri, May 10, 2013 at 12:36 PM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:
> 
> > Quoting Vallevand, Mark K (Mark.Vallevand at UNISYS.com):
> > > Actually, I've had good success using Unix domain named sockets for
> > communications between programs in containers and host.  Perhaps they are
> > in a shared name space.  But, don't change it.  :-)  It works.
> >
> > Right.  Abstract unix domain sockets shouldn't work across network
> > namespaces, but regular ones do as they're controlled by the file
> > space.  Agreed, don't want those changed :)
> >
> > -serge
> >