> 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 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.
>
> Regular process restart is of course application dependent, but e.g.
> Firefox actually restarts relatively graciously: I just killed mine and
> the new instance reopened all my tabs (a pleasant surprise--I expected
> the Restore Session ("Well this is embarrassing") window I was used to).
> Maybe there is a couple of classes that the restart falls into:
>
> - no problems restarting anytime
>
> - availability problems but no data loss on restart (easy restart but
> maybe needs user confirmation)
>
> - some out-of-process support needed (file rotation/cleanup, etc)
>
> - user intervention required (saving files, etc).
>
>
> I believe that seamless upgrades are an attractive goal. I am not
> arguing for infinite upgrades---only a fresh install can guarantee
> getting all new technologies that one wouldn't get through upgrades
> because they may not even existed at the original installation. My point
> is that the reinstall decision should be in principle driven by the
> user, not by the OS release schedule.
>
>
>
> --
> devel mailing list
> [email protected]
> https://admin.fedoraproject.org/mailman/listinfo/devel
> --
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel
