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
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
