Re: DBus reconnect support (initial attempt)

[Tom Parker <palfrey tevp net>]

Colin Walters wrote:
> On Sun, 2005-03-13 at 23:29 +0100, Tom Parker wrote:
> > One of the things that NM has needed for a while is the ability to 
> > properly handle Dbus disconnects, and to reconnect sanely. 
> I don't think we should really try to support this.  Restarting D-BUS
> should be viewed like trying to live-restart a new kernel.  There's so
>
> You should just have to reboot, IMO.

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. However, I don't 
think that restarting D-BUS should be counted as anywhere even close to 
being like a new kernel. Heck, I'd rather if we didn't have to restart 
for new kernels (hello kexec...), and I certainly can't see any reason 
why we should restart for D-BUS. 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. 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.

Given that D-BUS will occasionally (weeks, months) get restarted, we 
have 3 choices
1) Drop everything, die, come back to the user a bit later with 
zero-memory of our state. Bad choice, but that's what we're doing now.
2) Drop D-BUS/HAL, but keep state loaded. Assume that D-BUS/HAL being 
brought down is a temporary thing (or if it isn't, then odds are we're 
getting restarted soon, so no worries about staying around in memory), 
and try and get them back. This is what my patches would head towards. 
Makes returning back to the last known (and ergo most likely to still be 
best) state really easy. Plus, we get to keep all sorts of cached things 
like how long since the last DHCP lease, which reduces the amount of 
unecessary crap floating around which is always a good thing.
3) Save state, *then* die. When we're eventually restarted (probably not 
as soon as we'd like, but when the system gets around to starting our 
service again), we at least have a state that's hopefully only a few 
tens of seconds old, and so is pretty decent as a starting base. This is 
likely to be even more of a headache than decent restarting, and I'd 
advise against it.

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

Tom Parker
--
palfrey tevp net
Unix. Because restarts are for reformats.