On Thu, 24.01.13 15:28, Miroslav Suchý (msuchy@xxxxxxxxxx) wrote: > On 01/23/2013 07:50 PM, Lennart Poettering wrote: > >The thing is that doing on-line updates only works for stuff you can > >restart, and that doesn't mind that things are not atomically > >updated. However, much (most?) of our code isn't like that. Anybody who > > What could not be restarted? And what we can do to fix that? The kernel for starters, dbus too, bash, ssh daemon processes of open connections, gdm, ... If you restart any of those you bring down the entire machine basically, or bring down at least the bits you really want to avoid, i.e. the user's sessions... Then all code that runs that is not a system service is difficult to restart from a system script. How do you plan to restart Evolution or Firefox, or Gimp? Of course, you can say that it's OK if those processes just stay running, and then are updated when the user reboots the machine the next time, or restarts his apps the next time, or logs out and back in the next time, but until then you have versions of these programs in memory that might not be able to find their own resources anymore, because those got replaced, or they might find them in different versions than they might expect. But let's pretend for a minute that there was a way how you could restart the kernel, dbus, and everything else without taking the machine or user session down, how would you figure out *what* precisely you need to restart? There are some scripts floating around that try to figure that out via "ldd", but that's very incomplete, because that assumes the only kind of dependency that was relevant were shared library deps -- but there are more than that and in times of dlopen() ldd doesn't work comprehensively for those anyway. Applications have deps on all kinds of data in /usr/lib, not just shared libraries. Such as locale data, icons, fonts, artwork, documentation. And much of that might be continously mapped into memory, and others only temporarily. How are you going to figure out that? I mean, here's an example: let's say openssl is updated, which is pulled in by a ton of other things, for example the libc NSS LDAP module. The libc NSS is used by at least half of all processes running on your system, and they all dlopen() the NSS module. So how do you now figure out which ones that are and how do you then figure out what the heck you need to do to get them restarted? So, you can ignore all of that, but then you have to think about what you actually accomplished by your upgrade? You updated a couple of libraries, and maybe managed to restart a few processes using them, but for the rest of them the vulnerable openssl version is still in memory, still actively used, even though your update script exited successfully leaving the user under the impression that all was good now and that after he made this upgrade his machine was not vulnerable anymore. So you kinda promised the user online updates, but you actually just updated a number of things, and leaving the biggest chunk of code in memory still, without a chance to restart it or even figure out what it is that you left unrestarted. Of course, you could tell the user as last step of your script to "please reboot now", but if you do that your update isn't "online" anymore, but is awfully close to real offline upgrades, except that during the upgrade period you have a ton of processes around that might be seriously confused by not being able to find their own resources anymore or in wrong versions... > If this work for Debian/Ubuntu, why it could not work for Fedora? Will, because it doesn't work for them either. It works "well enough" for the knowledgeable, and that's what they focus on. I mean, just think about it: every new Fedora release sofar came with a new kernel version. The only way how to upgrade the kernel probably is by taking the machine offline for a while and rebooting. If you are willing to ignore everything I said above, how would your script keep the machine online during a kernel upgrade? > >tried to update the Firefox RPM while it is running knows that this > >doesn't end well, and you frequently have to manually kill firefox to > >get it back into a usual state. > > Interesting. Although I'm doing yum upgrade quite frequently I do > not have such experience. Well, sooner or later you'll run into that with Firefox, or with some other app. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
