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

[Christian Seiler]

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.

-- Christian