[systemd-devel] Client logging to journald without libsystemd-journal.so

[Colin Walters]

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.