[lxc-devel] [PATCH] move monitor-fifo and monitor-sock to /run
Serge Hallyn
serge.hallyn at ubuntu.com
Wed Sep 11 22:01:01 UTC 2013
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
More information about the lxc-devel
mailing list