On Tue, Feb 19, 2013 at 6:38 AM, Dominique Leuenberger a.k.a. Dimstar <dimstar@opensuse.org> wrote:
But 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 :^) On Tue, Feb 19, 2013 at 5:50 AM, Andreas Schwab <schwab@suse.de> wrote:
I 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? On Tue, Feb 19, 2013 at 7:17 AM, Ruediger Meier <sweet_f_a@gmx.de> wrote:
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. On Tue, Feb 19, 2013 at 8:36 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org