Re: DBus reconnect support (initial attempt)



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]