Proposed F19 Feature: Fedora Upgrade - using yum

[Lennart Poettering]

On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosowski at nist.gov) wrote:

> On 01/24/2013 06:12 PM, Lennart Poettering wrote:
> >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 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...
> 
> This is a pessimistic view but I think it's not as intractable.
> 
> There are two separate aspects to it: discovery what needs to be
> restarted, and the actual process of restarting. The discovery is
> almost there: we know the resources (libs, files, etc) that were
> replaced, so it's a matter of walking the list of running processes
> and checking if they depend on those resources. I can see how
> transient I/O, including dlopen() could be tricky, but I don't think
> it's fundamentally impossible---at worst, it'd be implementing some
> sort of /proc/1234/history-of-opened-fd mechanism.

That doesn't work. Let's say my app needs to display a certain icon in
some dialog. The next version of that app doesn't need that icon
anymore, so on upgrade the icon is deleted. At the same time the user is
still running that app, and then enters the dialog. The app now looks
for the icon, and doesn't find it. Bang.

There is no sane way to determine all these dependencies, because many
of them are never explicit, and only temporary in nature. Well written
apps load a lot of resources lazily. That has the side effect that you
can never know those deps, until they are actually needed.

The icon thing is just one example, you can now extrapolate from that...

> That leaves the restarting: again it seems to me that is not as
> hopeless as you make it sound, either: kernel is hardest but even
> there people are working on ksplice. Many services are designed to
> be restarted, like DHCPD which doesn't even have an online reload
> but has to be bounced if the DHCP data file changes.

"kernel is hardest"? Yuck. Kernel is not feasible. And much of the rest
isn't either.

I'll wait your patches for the kernel to allow seamless upgrades of the
kernel without reboots.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.