[lxc-devel] [PATCH] move monitor-fifo and monitor-sock to /run

[Serge Hallyn]

Quoting Christian Seiler (christian at iwakd.de):
> Hi Serge,
> 
> >> Only problem: it's not thread-safe... And in contrast to openat() or the
> > 
> > We could just do process_lock() around the whole shebang if we had to.
> > 
> > But I can't think offhand of any reason why we'd ever need to go from
> > the socketname back to the lxcpath, so using md5sum really shouldn't
> > have any downsides.
> 
> One downside: it's less clear what container this is now for, when
> looking through /run. On the other hand, I don't really care that much
> about this, I just wanted to throw in how one can in principle get
> around the 108 byte limit - not whether that's necessarily very practical.
> 
> >> One doesn't even need socket passing for this, since the socket can be
> > 
> > socket passing I'd understand, and that could be a neat solution.  But I
> > don't understand why the above would work.  Since the pids had forked,
> > the fd numbered r would be meaningless to the original task, wouldn't
> > it?  I must be missing something cool, though.
> 
> No, r is the return code, the fd is always passed from parent to child
> (implicitly via fork), the child never passes anything back.
> 
> The real trick behind the example I gave was that after fork() they are
> two different file descriptors, but still point to the same socket. And
> bind() doesn't operate on file descriptors, but rather on sockets. So
> anything the child process does to the socket (except close()) will have
> an effect on the parent process.

Oooh, gotcha.  That just may be our solution!  At that point the only
potential problem would be reaaaaaaaly-long container names :)

-serge