Sorry about the tone in the last message, it was unnecessary. There's just some history here dating from the libxml2 days...
On Thu, 2012-11-08 at 17:38 +0100, Daniel P. Berrange wrote: > Yeah, we've looked at & borrowed code from GLib in a few cases > now, notably threads and atomic ops. I've previously looked at > GLib's process spawning code, but didn't notice this particular > item. Originally we did have an API fairly similar to the > g_spawn_async_with_pipes API, but it is proved fairly cumbersome > to use, so we've put together a much more flexible API now [1]. Yeah, I've been working on a new one: https://bugzilla.gnome.org/show_bug.cgi?id=672102 > Possible, though I feel it is a little nasty, not least because when > when journald then uses SCM_CREDS to find out the sender identity it > will be getting the wrong pid and potentially wrong uid/gid too. This is an interesting case...conceptually it's true that it's a new pid, but I think it's a lot more useful usually what *code* it's running; ordinarily, that'd be an executable. But here we're running code from the parent just before executing a new child. Pretty much any error in fork-before-exec should be fatal, right? So in the case where you're logging an error (e.g. setuid() failed, prctl() failed), the pid is going to be irrelevant anyways since the process will soon exit. The uid/gid - yes, but on the other hand, the uid associated with the message will be the one that's conceptually "in control" at the moment. Regardless though of the approach taken (log from parent, log from forked-before-exec'd child), it'd probably be good to include some standard structured field saying that the code is being run in a child setup. "PREEXEC=1"? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
