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

Christian Seiler christian at iwakd.de
Wed Sep 11 21:02:02 UTC 2013


Hi Serge,

> Thanks, nice cleanup too.  One concern though - lxc_monitor_sock_name()
> just keeps making a longer and longer path, and it's limited to 108
> bytes.  Is there any reason not to use an abstract unix sock for it?
> The monitor-fifo doesn't have the length restriction so
> $rundir/lxc/$lxcpath/monitor-fifo is ok for it.

FWIW, the following can be used to 'circumvent' this problem:
  1. chdir()
  2. bind()/connect() with relative path
  3. chdir() back

Only problem: it's not thread-safe... And in contrast to openat() or the
such, there's no bindat() and connectat() in Linux as far as I can tell,
although FreeBSD is apparently discussing it...

(Of course, the following would also work if you want thread safety,
although it's a bit crazy (sketch):

sock = socket(AF_UNIX, SOCK_STREAM, 0);

pid = fork();
if (pid == 0) {
  struct sockaddr_un un;
  un.sun_family = AF_UNIX;
  strcpy(un.sun_path, "monitor-fifo");
  chdir(dirname);
  r = bind(sock, (struct sockaddr *)&un,
       offsetof(struct sockaddr_un, sun_path) + 13); // or connect();
  exit(r);
} else if (pid > 0) {
  r = waitpid(pid, ...);
  if (WIFEXITED(r))
    r = WEXITSTATUS(r);
  else
    r = -1;
} else {
  // fork failed...
}

if (r == -1)
  // bind/connect failed

r = listen(sock, ...);

One doesn't even need socket passing for this, since the socket can be
pre-created in the parent process before the fork and the bind affects
the entire socket, including the version of the parent's process.

But as I said, might be a bit crazy. On the other hand, one could
encapsulate this in the UNIX socket creation routines to only do this if
the length of the path is longer than 107 bytes... I don't know, just
throwing stuff out there.)

-- Christian




More information about the lxc-devel mailing list