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