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
