On Mon, Feb 18, 2013 at 2:14 PM, Cristian Rodríguez wrote:

...

...

If you propose zypper ps then you dont understand what I'm talking about, zypper ps will not prevent any of the problems I mentioned. please read http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates again.

I mean zypper ps can be used to figure out which updates need that (which will be a tiny portion of all updates).

zypper ps only list files deleted or changes *after* the fact.. it is much better to do things when none of the "to-be-updated" components are running.

The "Offline System Updates" feature does *exactly* what is needed and was probably designed by someone who underwent all the upgrade pains :-)

We just need to make it work in openSUSE.

It needs two restarts, so it's quite unacceptable when updating a minor component of the system. You could say, apply offline when any of the packages are marked needs-blah-restart. It would be even more preferrable to stop X, apply the update (invoking the update-system.target on systemd) and then restart X, when the only thing that's flagged for restart is the desktop. Or plainly update the packages if there's no restart of anything needed. AFAIR, zypper ps could be given a file and it would resolve for you which services are using it, before the fact. I'm checking now... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Feb 18, 2013 at 2:31 PM, Cristian Rodríguez wrote:

...

You could say, apply offline when any of the packages are marked needs-blah-restart. It would be even more preferrable to stop X, apply the update (invoking the update-system.target on systemd) and then restart X, when the only thing that's flagged for restart is the desktop.

I hope you see that what you are proposing makes things even more complicated than just making it all offline.

As always, convenience to the user is inconvenience to the developer. Yes, it is more complicated. But it should only stand on already provided tools, so it's not as complicated as it seems. I checked zypper, and sadly, as you said, zypper ps only works after the fact. Bummer. Anyway, this still applies to marked updates. There's no need to propose an offline, rebooting update if there's no restart mark on the patches involved. And, zypper ps could conceivably be extended to also check for would-be restarts (you could give it a list of packages, and assuming every file on those packages got modified, it could tell you want would need to be restarted), although that's a bigger proposition. But just by checking patch flags you'd have a huge improvement. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 18 February 2013, Cristian Rodríguez wrote:

El lun 18 feb 2013 14:22:31 CLST, Claudio Freire escribió:

...

It needs two restarts, so it's quite unacceptable when updating a minor component of the system.

zypper up will always be an option..

...

You could say, apply offline when any of the packages are marked needs-blah-restart. It would be even more preferrable to stop X, apply the update (invoking the update-system.target on systemd) and then restart X, when the only thing that's flagged for restart is the desktop.

I hope you see that what you are proposing makes things even more complicated than just making it all offline.

The most complicated thing is to ask all users to log off to be able to reboot. This offline update feature is another thing which may be useful on single user desktop systems only (if it's useful at all). Also it conflicts with "automatic updates". Or do we have auto-reboot also now - it wouldn't wonder me ... 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 ... cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2013-02-18 at 17:09 -0600, Michael Catanzaro wrote:

Back to my original question:

1) Does it work for anyone *right now*?

No: we do not start / enable the systemd services needed for this by default.

2) If not, should we maybe patch GNOME Shell to hide this option for the time being?

I would prefer to patch the application that writes the updates-prepared file... gnome-shell only verifies on that file and shows the menu accordingly... hiding it might in worst case cause some other effects to pop-up if somebody enables the systemd service... you never know :) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Quoting Michael Catanzaro :

On Tue, 2013-02-19 at 00:20 +0100, Dominique Leuenberger wrote:

...

I would prefer to patch the application that writes the updates-prepared file... gnome-shell only verifies on that file and shows the menu accordingly... hiding it might in worst case cause some other effects to pop-up if somebody enables the systemd service... you never know :)

Dominique

PackageKit is what is creating the file of course. By default it is built with --enable-systemd --enable-systemd-updates, of which we don't want the latter. But when I build PackageKit with --disable-systemd-updates I get this error:

[ 436s] configure: error: conditional "HAVE_SYSTEMD" was never defined. [ 436s] Usually this means the macro was only invoked conditionally.

I don't know autoconf, but I'm pretty sure this is an error in upstream's configure.ac that needs fixed? Then HOPEFULLY that will stop creation of the prepared update file and we'll be good.

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. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Feb 19, 2013 at 6:38 AM, Dominique Leuenberger a.k.a. Dimstar 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 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 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 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