On Tue, Feb 19, 2013 at 6:38 AM, Dominique Leuenberger a.k.a. Dimstar
Post by Dominique Leuenberger a.k.a. DimstarPost by Michael CatanzaroBut I'm honestly not sure if that option will work as advertised or not.
Looking at the PackageKit tree, it looks like that will disable all the
code in contrib/systemd-updates, but I think the code that writes the
file is in src/plugins/pk-plugin-systemd-updates.c and maybe it will run
regardless, I'm not sure.
Thanks for finding the exact location and already digging into the issue.
With your great pre-work, I created a PK package (currently building
offline) with this disabled.
I expect the package to be submitted later today.
Fix submitted to GNOME:Factory for review: SR#155782. The patch has already
been merged upstream.
That was fast :^)
Post by Dominique Leuenberger a.k.a. DimstarI checked zypper, and sadly, as you said, zypper ps only works after
the fact.
You could call lsof directly, which is what zypper ps is actually using.
Yes, I thought so. From the above comment, it looks like that would
have to be a patch to PackageKit... right?
Just fix (or don't use) packages who have problems with online updates -
that's what "sane" people would to. Anybody who tells me in 2013 that I
have to reboot just to update an arbitrary webrowser like firefox has
obviously some other problems to be solved first ...
Sadly, I don't think that's a sensible requirement to ask of most
complex applications. Online updates change their data and code files
without warning. You'd be forcing all applications to load all data at
launch time, to avoid them being changed afterwards and being
inconsistent when actually needed. That would suck up a lot of RAM.
Instead, perhaps a "graceful failure" mode, where the app just tells
you to restart (or restarts by itself) would be preferrable.
In any case, it's a complex matter. No, probably the best thing to do
is to just be aware that some applications need an offline update.
Only "offline" has many degrees. Restart asap, application offline,
desktop offline, and finally system offline.
Most offline levels, except system offline, would be served by the
script mentioned before, that checks open files with lsof. Call that
"transaction guards". Implementing transaction guards (checks to be
done before applying a transaction) would be a nontrivial but useful
systemd/packagekit patch.
1. Current state: I do a "zypper update", then "zypper ps" and it shows
me what needs to be restarted. Pretty good chance it is nothing or one
or two daemons which can be restarted safely without anyone noticing.
Even if it is not the case, often the remaining problems are just
running applications dynamically linked against replaced modules - which
actually do not need restart. If I'm unlucky, I need users to relogin
and only if I'm very unlucky, I need to reboot the system.
2. Offline updates: for many situations which didn't require it before,
you need to do a reboot now. Which requires either to wait untill all
users log out (with more users, this may take some time) or forcibly
shutting down their sessions (I really don't understand why you chose
Firefox which doesn't make much difference between SIGTERM and a crash
as your example).
Summary? There isn't a single situation in which offline updates would
be less intrusive or less annoying for the users or for the admin. In
any case when I need user to restart a certain application, you need it
as well. In any case when I need user to relogin, you need it as well.
In any case when I need to reboot the system, you need it as well. On
the other hand, there are many situations when I don't need to do
anything and you end up with shutting down all sessions (forcibly or
waiting for users) and rebooting the system.
You are talking about protecting the user from a potential application
crash after an update. But you forget to tell us that you are
"protecting" them by requiring a full system reboot so that the
application has to go down anyway.
I believe the whole point is to protect the user from half-applied
updates. When you perform an update offline and atomically, very few
things can go wrong in the middle, which lowers considerably the risk
of a broken system if something goes wrong (eg: power off). That's
assuming the update itself is sane, of course. Only FS snapshots as
discussed somewhere in the thread can give you rollback capability on
such a situation.
When you do it online, if something fails, well, your system will
probably be hard to fix. Sometimes just reinstalling the packages in
question fixes it, but sometimes it does not (I remember that used to
happen rather often in SuSE 8, since it installed packages as it was
downloading them). But not only that, applications that are running
while updated will go on running with the old code. For simple or
specially prepared applications, as most are, that's no problem. But
in the firefox case, there are lots of files involved in running it,
and if they change unexpectedly, things start to malfunction. That
doesn't happen with offline updates, and is the whole point of offline
updates. When they're needed. Abusing (not using) them is wrong.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org