[RFC] Patch to allow a DBusConnection to be recreated from an fd

[Simon McVittie]

On 05/03/13 11:54, James Hunt wrote:
> As of version 1.6, Upstart supports stateful re-exec. This works fine except
> that any clients connected to it via D-Bus at the time it re-execs have their
> connections severed. This is handled currently by having those jobs respawn. A
> better solution would be to allow Upstart to recreate the DBusConnections
> post-re-exec.

So... is the idea here that Upstart (or in principle, any other service)
can remember its connection's address and fd, turn off close-on-exec on
that fd, re-exec itself, re-create a DBusConnection around the old fd,
and remain connected to the bus with the same unique name that it
previously had, without any of its clients receiving NameOwnerChanged?

As Lennart pointed out, DBusConnection is not just a fd: it buffers
incomplete incoming messages. If the old DBusConnection has read half a
message from the fd at the time you re-exec, the new DBusConnection will
start reading halfway through a message, fail to parse it and
disconnect. The new DBusConnection will also not know its own unique
name, because it hasn't seen the Hello() reply (which was sent to the
old one).

I'm sure there are more bits of state like this, and I doubt the
necessary complexity in libdbus to support serializing and deserializing
the entire DBusConnection state is something I'd be prepared to merge.

I think it'd be better to make Upstart's clients able to cope with a
change in name ownership, although even that is difficult to do cleanly.
If you wanted to avoid the Upstart name ever being un-owned, you'd have
to hand over the Upstart name to a helper process that responds to all
method calls with a special "please try again" error, re-exec, and take
the name back (letting the helper terminate).

    S