25.01.2013 22:27, Lennart Poettering пишет:
On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosowski@xxxxxxxx) 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...
Sorry but how such use case different from simple firefox update in
current release when it happened parallel with browsing?? It may also
lead to that unpredictable behavior. Off course you will say it
shouldn't be major release in stable Fedora. And off course it is true.
But anyone can't guaranty what even change or delete 1 file do not lead
to unstable app. So for that cases graphical application similar to
PackageKit suggests user reboot (and may suggest only reload certain
apps) with list of apps, based on maintainers expectation from ("suggest
reboot" in bodhi update system). I hope you do not suggest force reload
such apps for user of force always offline update for that thinks. In
that point of view "online" distro update differs only by amount of
updated packages which "suggest reboot" for user. And I may himself plan
reboot when I want...
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: Hubbitus@xxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
