DBus reconnect support (initial attempt)

[Colin Walters]

[ CC'ing dbus list as this discussion is important for writers of D-BUS
applications and for packagers ]

On Mon, 2005-03-14 at 23:49 +0100, Tom Parker wrote:

> I'd disagree. Yes, it'll be a pain in the ass to get right, and yup this 
> ain't exactly going to be the most tested code path.

I'm certain your posted code is full of races and problems; you just set
the connection to NULL, but NetworkManager has a number of threads and
idle handlers which are not expecting it to be NULL.  Some of the code
has g_return_if_fail (connection != NULL), but at best you get lots and
lots of error spew, and at worst NetworkManager segfaults.
These failure modes are a lot worse than simply running an old instance,
reliably.

>  However, I don't 
> think that restarting D-BUS should be counted as anywhere even close to 
> being like a new kernel. 

The kernel has a lot of jobs, but really it comes down to two things:

1) Drivers for hardware
2) Providing the required locking for inter-process communication,
   via the filesystem or sockets, etc.
   
D-BUS is exactly like 2.

> Heck, I'd rather if we didn't have to restart 
> for new kernels (hello kexec...), 

kexec is just a faster way of rebooting (hence the name "exec" which
implies resetting state); it doesn't magically upgrade you to a newer
kernel while it's running.

> and I certainly can't see any reason 
> why we should restart for D-BUS. 

Because it's too hard, and creates user expectations which will
ultimately not be met.  

> Especially as despite the fact that 
> more and more other tools are starting to become reliant on D-BUS, it 
> should still just be treated as just another service. 

But the difference with D-BUS is that it provides reliable communication
semantics between those services.  If the bus can go away arbitrarily,
you lose that.

> Even if it's just 
> on desktop machines, it's still very annoying when you have to restart 
> your machine to install something, as opposed to a few seconds of 
> downtime while the old version is removed and the new version brought up.

No one is suggesting you have to reboot to install something.  Windows
doesn't require that either.  I'm just suggesting that for a few
critical packages such as dbus and NetworkManager, you don't get the new
functionality or security update until you reboot.

> Given that D-BUS will occasionally (weeks, months) get restarted, we 
> have 3 choices

The system bus will be restarted on reboot, however often that happens.
For my personal system that's several times a day, as apm and acpi are
broken on my laptop.

> 1) [...]
> 2) [...]
> 3) [...]

The alternative I am suggesting is:
0) Assume the bus never goes away, and make sure distributors don't
   restart dbus or NetworkManager in package upgrade scripts

> My 2p. I think restarts of a whole system should be avoided, and that 
> graceful degradation is the way to go. 

I agree they should be avoided, but I would much rather have a system
that works 100% reliably on upgrades but requires occasional fast
reboots (and we could do plenty to optimize it) for a few packages,
instead of a system which works 75% of the time but the other 25% causes
random hard-to-debug application crashes and eventually requires a
reboot anyways to sort out.

For people on the dbus list, the initial thread is here:
http://mail.gnome.org/archives/networkmanager-list/2005-March/msg00022.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050314/7deef7b6/attachment.pgp