> 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 > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel >
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel