On Thursday 21 July 2011 16:51:17 Patrick O'Callaghan wrote: > Updating the on-disc binary of a running process has no effect on said > process, it simply creates a new file. New execs of the program will > execute from that file rather than the old one, but the old one will > persist until the last running instance of it dies. Of course problems > can in theory arise if a set of interacting processes are partially > updated, depending on exactly when each of them executes, but in > practice I've rarely seen any problems with this (mainly I think because > apps don't tend to change radically from one version to the next, > especially in their external interfaces). What about this scenario: an app A occasionally loads a library B in order to use some code from there. Suppose that while A is running (and did not load B yet because user interaction didn't require it so far) there is an update to both A and B (which goes to disk). After this happens, the system is in a potentially inconsistent state --- if a user interacts with A so that A asks to load B, the *updated* library B will be loaded, which can break A badly, depending on the difference between old and new B. If A is restarted, everything will be ok, of course, but until then the *old* A is running from memory, and loading the new B is a gamble, in general. For system daemons and services (and even for init AFAIK) this is being solved by the automatic restart of the service after the update (I guess this is in the rpm's "post"-part of the install), so the system is kept in consistent state. For DE and its apps, the story is different, since rpm cannot "restart" the whole DE while the user is logged in. So there is no way for a system to keep the DE and its apps in a consistent state after the update, if the user is still working in it. This happens fairly often, in the case of firefox I would say regularly --- every time I see firefox being updated in the yum listing, I save all tabs before the update begins, close it and reopen it after the update. Every time I miss to do that, I get burned by the running version of firefox starting to malfunction in all sorts of weird ways. Aside from firefox crashing/misbehaving regularly after an update, I remember that this happened once with ktorrent as well. It was updated while running (in the background), and it crashed when I opened up its window again. A simple restart fixed it. All that said, on F14 plasma never crashed on me, updates or otherwise. Of course, if I see kde* packages being updated in the yum listing, I either postpone the update for later, or save my data, logout and login after the update. I am not saying that this is a big issue, it rarely happens, but if you don't want nasty surprises, it's better to be on the safe side. HTH, :-) Marko _______________________________________________ kde mailing list kde@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
