On Thu, 2012-11-08 at 16:59 +0100, Daniel P. Berrange wrote: > The problem is that when libvirt does fork() to create client processes, > one of the things it does is to iterate from 0 -> sysconf(_SC_OPEN_MAX), > closing every file descriptor, except those in its whitelist.
You could iterate over the fds and just set them CLOEXEC, rather than actually closing them at that point. That's what we do in GLib: http://git.gnome.org/browse/glib/tree/glib/gspawn.c?id=a9eb1907a6451cdfe68f5924b138cfbeebc4dcf1#n1164 As a general rule, your project isn't using a standard framework like APR or GLib, and is in the process of slowly growing its own Unix API damage control layer + Windows abstraction, usually worth looking at how they approach problems. > Not least because traditional UNIX APIs > don't allow for atomically creating an FD with O_CLOEXEC set Yeah, but it's not too hard to make portable wrappers for most cases: http://git.gnome.org/browse/glib/tree/glib/glib-unix.c?id=a9eb1907a6451cdfe68f5924b138cfbeebc4dcf1#n60 http://git.gnome.org/browse/glib/tree/gio/gsocket.c?id=a9eb1907a6451cdfe68f5924b138cfbeebc4dcf1#n521 > The second blocker problem was figuring out a way to send log messages > using only APIs declared async-signal safe. Again this is so that we > can safely send log messages inbetween fork() and execve() which only > permits async signal safe APIs. The sd_journal_send() API can't be > used since it relies on vasprintf() which can allocate using malloc. The other approach is to use a pipe to write error messages back to the parent, and have it log them. That's probably what I'm going to change GLib to do. > The sd_journal_sendv() API is pretty close to what we'd want, but > the way you have to format the iovec doesn't quite work. IIUC, it > requires that each iovec contains a single formatted log item > string "KEY=VALUE". Populating data in such a way is inconvenient > for libvirt. For libvirt it was easier for us to use two iovec > elements for each log item, "KEY=" and "VALUE", so that we can > avoid doing the data copy implied by filling a single string with > "KEY=VALUE". Hmm...yeah. Maybe the wire protocol could actually support this better. This does sound like something that could be improved, regardless. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
