Discussion:
systemd offline updates - working for anyone?
Michael Catanzaro
2013-02-18 05:39:52 UTC
Permalink
I notice that in 12.3 "Install Updates & Restart" now frequently appears
on the GNOME shell menu as per
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates

I tried this a few months ago but never got it to work in openSUSE;
rather my computer just restarted normally. I figured it was being
worked on. But in 12.3 RC1 I have the same issue; my computer just
restarts without applying any updates. Is this working for anyone else?
It works fine for me in Fedora.*

* If by "fine" we are OK with it being confusingly redundant with the
existing GNOME update app. I get the impression that this feature is
only half-ready in GNOME 3.6, and we'd lose little by disabling it until
13.1.

As a side note, neither zypper nor YaST delete the prepared update list
(in /var/lib/PackageKit/) after an update, so the menu item remains even
when there's nothing to install. Not sure what component(s) are at
fault, but that really ought to happen.

Michael Catanzaro
Cristian Rodríguez
2013-02-18 06:05:21 UTC
Permalink
Post by Michael Catanzaro
I notice that in 12.3 "Install Updates & Restart" now frequently appears
on the GNOME shell menu as per
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates
I tried this a few months ago but never got it to work in openSUSE;
rather my computer just restarted normally. I figured it was being
worked on. But in 12.3 RC1 I have the same issue; my computer just
restarts without applying any updates. Is this working for anyone else?
It works fine for me in Fedora.*
* If by "fine" we are OK with it being confusingly redundant with the
existing GNOME update app. I get the impression that this feature is
only half-ready in GNOME 3.6, and we'd lose little by disabling it until
13.1.
As a side note, neither zypper nor YaST delete the prepared update list
(in /var/lib/PackageKit/) after an update, so the menu item remains even
when there's nothing to install. Not sure what component(s) are at
fault, but that really ought to happen.
Michael Catanzaro
This unfortunately is not implemented/tested in openSUSE. We need to
check it again for 13.1 as it will help to get rid of quite a few
annoying problems with "live system updates"..
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michael Catanzaro
2013-02-18 14:03:38 UTC
Permalink
Post by Cristian Rodríguez
Post by Michael Catanzaro
I notice that in 12.3 "Install Updates & Restart" now frequently appears
on the GNOME shell menu as per
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates
I tried this a few months ago but never got it to work in openSUSE;
rather my computer just restarted normally. I figured it was being
worked on. But in 12.3 RC1 I have the same issue; my computer just
restarts without applying any updates. Is this working for anyone else?
It works fine for me in Fedora.*
* If by "fine" we are OK with it being confusingly redundant with the
existing GNOME update app. I get the impression that this feature is
only half-ready in GNOME 3.6, and we'd lose little by disabling it until
13.1.
As a side note, neither zypper nor YaST delete the prepared update list
(in /var/lib/PackageKit/) after an update, so the menu item remains even
when there's nothing to install. Not sure what component(s) are at
fault, but that really ought to happen.
Michael Catanzaro
This unfortunately is not implemented/tested in openSUSE. We need to
check it again for 13.1 as it will help to get rid of quite a few
annoying problems with "live system updates"..
It is implemented (GNOME only) but I do feel like it's not tested. =)
Ruediger Meier
2013-02-18 14:20:15 UTC
Permalink
Post by Michael Catanzaro
I notice that in 12.3 "Install Updates & Restart" now frequently
appears on the GNOME shell menu as per
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates
Isn't this a step backwards? I always do updates online and reboot only
on kernel updates (if I find it's worth to run the new kernel
immediately). Never had serious issues.

cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-18 15:02:15 UTC
Permalink
Post by Ruediger Meier
Post by Michael Catanzaro
I notice that in 12.3 "Install Updates & Restart" now frequently
appears on the GNOME shell menu as per
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates
Isn't this a step backwards? I always do updates online and reboot only
on kernel updates (if I find it's worth to run the new kernel
immediately). Never had serious issues.
No. it is an step to sanity :-)
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-18 16:01:15 UTC
Permalink
On Mon, Feb 18, 2013 at 12:02 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Post by Ruediger Meier
Post by Michael Catanzaro
I notice that in 12.3 "Install Updates & Restart" now frequently
appears on the GNOME shell menu as per
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates
Isn't this a step backwards? I always do updates online and reboot only
on kernel updates (if I find it's worth to run the new kernel
immediately). Never had serious issues.
No. it is an step to sanity :-)
Care to elaborate?

Many messages that tell you to reboot should actually just tell you to
re-login. There's a big difference there, regarding running services.

PS: debian's gnome 3 has the same issue. I'd say it's upstream.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-18 16:13:17 UTC
Permalink
Post by Claudio Freire
Many messages that tell you to reboot should actually just tell you to
re-login. There's a big difference there, regarding running services.
Yeah, the package manager does not know if you need to reboot or
re-login.
that would require having a list of software which is known to require
reboot for upgrade..

I'm afraid that for this to work as expected ( that's different from
getting it to work)
It needs to apply the updates in a all-or-nothing transaction and
return sucess or fail.
Currently the package manager installs updates one by one using rpm
--force.. that's insane.. but it is the way it is :-|
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-18 16:23:15 UTC
Permalink
On Mon, Feb 18, 2013 at 1:13 PM, Cristian Rodríguez
Post by Claudio Freire
Many messages that tell you to reboot should actually just tell you to
re-login. There's a big difference there, regarding running services.
Yeah, the package manager does not know if you need to reboot or re-login.
that would require having a list of software which is known to require
reboot for upgrade..
Patches, coming from the updates repo, usually do have the
corresponding flag. In any case, it is quite possible to decide which
of those is required, after the fact, as zypper ps will let you know
which services need to be restarted (and deciding which require a
re-login or re-boot is quite possible).

And, this is the fun thing, linux will happily work until you do so.
I've only ever had issues with widespread system changes (ie: updating
KDE version or some humongus package that is depended on by a large
chunk of the system). Hotplug might misbehave if kernel modules have
been updated, but otherwise running binaries will go on running by
grace of orphan inode magic. In fact, zypper ps does just that,
inspect /proc looking for processes with orphan inodes in their mapped
space.

So... having a tool that already tells you what you need to restart
(zypper), and having updates already marked like so, I guess it should
be quite straightforward to pass along that message to the user, don't
you think?
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-18 16:24:42 UTC
Permalink
On Mon, Feb 18, 2013 at 1:13 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Currently the package manager installs updates one by one using rpm
--force.. that's insane.. but it is the way it is :-|
That's not insane. That's broken.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-18 16:29:03 UTC
Permalink
Post by Claudio Freire
On Mon, Feb 18, 2013 at 1:13 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Currently the package manager installs updates one by one using rpm
--force.. that's insane.. but it is the way it is :-|
That's not insane. That's broken.
Well, in my opinion yes.. but that was the call made by the person that
maintain the package manager, there are probably reasons why it is still
working that way.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-18 16:33:26 UTC
Permalink
On Mon, Feb 18, 2013 at 1:29 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Post by Claudio Freire
On Mon, Feb 18, 2013 at 1:13 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Currently the package manager installs updates one by one using rpm
--force.. that's insane.. but it is the way it is :-|
That's not insane. That's broken.
Well, in my opinion yes.. but that was the call made by the person that
maintain the package manager, there are probably reasons why it is still
working that way.
I can't imagine what those reasons could be, and that in fact explains
why every time I tried to use that package manager (instead of yast),
every time I got some kind of broken system. So whatever reasons they
have, they're simply poor reasons, as they result in system breakage.
I can't imagine a reason good enough to warrant system breakage.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Stefan Seyfried
2013-02-18 20:32:33 UTC
Permalink
Post by Claudio Freire
I can't imagine what those reasons could be, and that in fact explains
why every time I tried to use that package manager (instead of yast),
"that package manager" is zypper. And yast is doing exactly the same.
--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
fire, and you can't be bothered to figure out about lighter
fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Marcus Meissner
2013-02-18 16:27:01 UTC
Permalink
Post by Claudio Freire
Many messages that tell you to reboot should actually just tell you to
re-login. There's a big difference there, regarding running services.
Yeah, the package manager does not know if you need to reboot or re-login.
that would require having a list of software which is known to require
reboot for upgrade..
Our updates can be tagged wiuth "needs reboot" "needs desktop relogin"
and "needs package manager" restart and we usually tag them.

Not all desktop restarts or reboot tags are necessary however, so
you only see this seldom.
I'm afraid that for this to work as expected ( that's different from
getting it to work)
It needs to apply the updates in a all-or-nothing transaction and return
sucess or fail.
Currently the package manager installs updates one by one using rpm
--force.. that's insane.. but it is the way it is :-|
Ciao, Marcus
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michael Catanzaro
2013-02-18 22:59:48 UTC
Permalink
Post by Cristian Rodríguez
Yeah, the package manager does not know if you need to reboot or
re-login.
that would require having a list of software which is known to
require
reboot for upgrade..
Well for this discussion the concern is the difference between offline
updates and online updates. Right now it is "anything that installs
a .desktop can be safely updated online, anything else should be an
offline update." Upstream acknowledges that's dumb and will come up with
something better eventually.

(And when preparing patches for openSUSE the packager is responsible for
selecting whether to recommend relogin or reboot.)
Post by Cristian Rodríguez
I'm afraid that for this to work as expected ( that's different from
getting it to work)
It needs to apply the updates in a all-or-nothing transaction and
return sucess or fail.
That's exactly how systemd does it. =)
Post by Cristian Rodríguez
Currently the package manager installs updates one by one using rpm
--force.. that's insane.. but it is the way it is :-|
Cristian Rodríguez
2013-02-18 23:18:37 UTC
Permalink
Post by Michael Catanzaro
That's exactly how systemd does it. =)
Maybe I am misunderstanding something.

SUSE's package manager zypp install packages one by one,this is done by
executing the rpm binary.
there are no transactions involved and there is no warranty of
consistency either.

Yes.This is madness, but it is the way it works.

systemd of course does not have a package manager, so it must call
zypper up or dup with the appropiate parameters in order to behave
exactly like a human-made upgrade.

Does the implementation internally do this or is calling rpm directly ?
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michael Catanzaro
2013-02-18 23:34:30 UTC
Permalink
Post by Cristian Rodríguez
Does the implementation internally do this or is calling rpm directly ?
I'm not sure what exactly it's doing but it's all one big transaction.
If you read the description on the systemd wiki, Lennart says he takes a
btrf snapshot and just rolls back to that if the update fails. (I don't
understand how that works though, when we're using ext4.)
Cristian Rodríguez
2013-02-18 23:45:51 UTC
Permalink
Post by Michael Catanzaro
Post by Cristian Rodríguez
Does the implementation internally do this or is calling rpm directly ?
I'm not sure what exactly it's doing but it's all one big transaction.
If you read the description on the systemd wiki, Lennart says he takes a
btrf snapshot and just rolls back to that if the update fails. (I don't
understand how that works though, when we're using ext4.)
afaik ext4 does not have an snapshotting capability therefore I guess
you are at the mercy of the result of the upgrade.. ^_^
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-19 01:13:39 UTC
Permalink
On Mon, Feb 18, 2013 at 8:18 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Post by Michael Catanzaro
That's exactly how systemd does it. =)
Maybe I am misunderstanding something.
SUSE's package manager zypp install packages one by one,this is done by
executing the rpm binary.
there are no transactions involved and there is no warranty of consistency
either.
Yes.This is madness, but it is the way it works.
systemd of course does not have a package manager, so it must call zypper up
or dup with the appropiate parameters in order to behave exactly like a
human-made upgrade.
Does the implementation internally do this or is calling rpm directly ?
Oh... I think I can now understand what happens with gnome's updater
that I attributed to running rpm package by package. I've never
actually experienced interrupted installations (only interrupted
downloads - and zypper handles them pretty well). Gnome's dependency
resolution must be broken somehow, because the kinds of breakages I
experienced usually related to dependencies and wrongly mixing repos
(in a way zypper never mixed).

Note: this applies to apper/packagekit too. I've stopped using all
desktop-provided updaters because of this.

Anyway, transactions are a good thing, and what systemd does is
actually quite beneficial even if done without FS snapshots (because
far fewer failure modes are possible when committing the transaction
than they are during preparation of it). The rebooting thing is the
only problem here. Zypper does have the information of whether or not
a reboot is required for updates, so the system needs only inform
systemd and gnome about it.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Philipp Wagner
2013-02-18 16:23:53 UTC
Permalink
Post by Claudio Freire
Care to elaborate?
Many messages that tell you to reboot should actually just tell you to
re-login. There's a big difference there, regarding running services.
Think of a Firefox update. Firefox consists of many different files in
JavaScript, XUL and other languages, describing the UI, different parts
of the application, etc. When showing e.g. a new tab with the Addon
manager, one of those files is loaded from disk and displayed.

Now, if you update Firefox, those files get replaced with a newer version.

If one (or many) users have still a Firefox instance running, this
results in a mix of old and new Firefox code running (the binary and the
main libraries are still the old ones, since they are running, but many
components that are loaded on demand, like the addon manager files
mentioned before, are now from the new Firefox version. I guess many
people have already seen that happening, and that's also the reason why
Ubuntu has a custom Firefox add-on that displays an information bar
inside Firefox telling you to restart your browser.

So the right way to do updates for software like this is to wait until
no Firefox instance is running on the machine. The easiest time where
this is guaranteed is actually during shutdown or boot.

HTH

Philipp
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-18 17:20:28 UTC
Permalink
Post by Philipp Wagner
So the right way to do updates for software like this is to wait until
no Firefox instance is running on the machine. The easiest time where
this is guaranteed is actually during shutdown or boot.
Exactly, that will be the conclusion of any sane person that has
suffered the perils of "live updates"..

It does not matter if it is similar to $INSERT_YOUR_HATED_OS_HERE , the
only things that matter is :

a) It works or not
b) makes the issues derived from live updates go away.
c) End of list.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Guido Berhoerster
2013-02-18 17:30:24 UTC
Permalink
Post by Cristian Rodríguez
Post by Philipp Wagner
So the right way to do updates for software like this is to wait until
no Firefox instance is running on the machine. The easiest time where
this is guaranteed is actually during shutdown or boot.
Exactly, that will be the conclusion of any sane person that has
suffered the perils of "live updates"..
It does not matter if it is similar to $INSERT_YOUR_HATED_OS_HERE ,
a) It works or not
b) makes the issues derived from live updates go away.
c) End of list.
A "Live Upgrade" (the one used in the pre-Solaris 11 days) is
actually a pretty good solution to this kind of problem, with
reduced downtime while applying updates and the ability to go
back to the old system. Way better than this idiotic idea copied
from Windows/OS X...
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Philipp Wagner
2013-02-18 17:45:05 UTC
Permalink
Post by Guido Berhoerster
Post by Cristian Rodríguez
Post by Philipp Wagner
So the right way to do updates for software like this is to wait until
no Firefox instance is running on the machine. The easiest time where
this is guaranteed is actually during shutdown or boot.
Exactly, that will be the conclusion of any sane person that has
suffered the perils of "live updates"..
It does not matter if it is similar to $INSERT_YOUR_HATED_OS_HERE ,
a) It works or not
b) makes the issues derived from live updates go away.
c) End of list.
A "Live Upgrade" (the one used in the pre-Solaris 11 days) is
actually a pretty good solution to this kind of problem, with
reduced downtime while applying updates and the ability to go
back to the old system. Way better than this idiotic idea copied
from Windows/OS X...
How does it work?

Philipp
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Guido Berhoerster
2013-02-18 17:56:30 UTC
Permalink
Post by Philipp Wagner
Post by Guido Berhoerster
Post by Cristian Rodríguez
Post by Philipp Wagner
So the right way to do updates for software like this is to wait until
no Firefox instance is running on the machine. The easiest time where
this is guaranteed is actually during shutdown or boot.
Exactly, that will be the conclusion of any sane person that has
suffered the perils of "live updates"..
It does not matter if it is similar to $INSERT_YOUR_HATED_OS_HERE ,
a) It works or not
b) makes the issues derived from live updates go away.
c) End of list.
A "Live Upgrade" (the one used in the pre-Solaris 11 days) is
actually a pretty good solution to this kind of problem, with
reduced downtime while applying updates and the ability to go
back to the old system. Way better than this idiotic idea copied
from Windows/OS X...
How does it work?
By performing the upgrade not on the running system but a clone
of it, after finishing you can reboot into the upgraded system or
go back to the old one. Live Upgrade used to require two separate
filesystems for that but nowadays in the era of ZFS/btrfs cheaper
snapshots can be used. This could probably easily be implemented
with snapper, zypper and a bit of duct tape...
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michael Catanzaro
2013-02-18 23:02:59 UTC
Permalink
Post by Philipp Wagner
Post by Claudio Freire
Care to elaborate?
Many messages that tell you to reboot should actually just tell you to
re-login. There's a big difference there, regarding running services.
Think of a Firefox update. Firefox consists of many different files in
JavaScript, XUL and other languages, describing the UI, different parts
of the application, etc. When showing e.g. a new tab with the Addon
manager, one of those files is loaded from disk and displayed.
Now, if you update Firefox, those files get replaced with a newer version.
If one (or many) users have still a Firefox instance running, this
results in a mix of old and new Firefox code running (the binary and the
main libraries are still the old ones, since they are running, but many
components that are loaded on demand, like the addon manager files
mentioned before, are now from the new Firefox version. I guess many
people have already seen that happening, and that's also the reason why
Ubuntu has a custom Firefox add-on that displays an information bar
inside Firefox telling you to restart your browser.
So the right way to do updates for software like this is to wait until
no Firefox instance is running on the machine. The easiest time where
this is guaranteed is actually during shutdown or boot.
HTH
Philipp
Aha, you broke the use case! Upstream specifically wants to exclude
"applications" from offline updates, and use offline updates only for
"OS components" -- currently defined by whether or not the package
installs a .desktop file.

(But gpk-update-viewer doesn't know it shouldn't be updating "system
components" and updates everything anyway.)
Philipp Wagner
2013-02-18 23:36:54 UTC
Permalink
Post by Michael Catanzaro
Post by Philipp Wagner
Post by Claudio Freire
Care to elaborate?
Many messages that tell you to reboot should actually just tell you to
re-login. There's a big difference there, regarding running services.
Think of a Firefox update. Firefox consists of many different files in
JavaScript, XUL and other languages, describing the UI, different parts
of the application, etc. When showing e.g. a new tab with the Addon
manager, one of those files is loaded from disk and displayed.
Now, if you update Firefox, those files get replaced with a newer version.
If one (or many) users have still a Firefox instance running, this
results in a mix of old and new Firefox code running (the binary and the
main libraries are still the old ones, since they are running, but many
components that are loaded on demand, like the addon manager files
mentioned before, are now from the new Firefox version. I guess many
people have already seen that happening, and that's also the reason why
Ubuntu has a custom Firefox add-on that displays an information bar
inside Firefox telling you to restart your browser.
So the right way to do updates for software like this is to wait until
no Firefox instance is running on the machine. The easiest time where
this is guaranteed is actually during shutdown or boot.
HTH
Philipp
Aha, you broke the use case! Upstream specifically wants to exclude
"applications" from offline updates, and use offline updates only for
"OS components" -- currently defined by whether or not the package
installs a .desktop file.
(But gpk-update-viewer doesn't know it shouldn't be updating "system
components" and updates everything anyway.)
From what I heard this .desktop-heuristic is only a workaround, until
the updates/packages contain this information itself. Is my
understanding correct? I'd think the packager is the one person most
qualified to judge whether offline updates for the given package would
be beneficial or not.

Philipp
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michael Catanzaro
2013-02-19 02:17:47 UTC
Permalink
Post by Michael Catanzaro
From what I heard this .desktop-heuristic is only a workaround, until
the updates/packages contain this information itself. Is my
understanding correct? I'd think the packager is the one person most
qualified to judge whether offline updates for the given package would
be beneficial or not.
Philipp
Yes, I think that's the plan.
Michal Kubecek
2013-02-19 11:36:54 UTC
Permalink
Post by Philipp Wagner
Post by Claudio Freire
Care to elaborate?
Many messages that tell you to reboot should actually just tell you to
re-login. There's a big difference there, regarding running services.
Think of a Firefox update. Firefox consists of many different files
in JavaScript, XUL and other languages, describing the UI, different
parts of the application, etc. When showing e.g. a new tab with the
Addon manager, one of those files is loaded from disk and displayed.
Now, if you update Firefox, those files get replaced with a newer version.
If one (or many) users have still a Firefox instance running, this
results in a mix of old and new Firefox code running (the binary and
the main libraries are still the old ones, since they are running,
but many components that are loaded on demand, like the addon
manager files mentioned before, are now from the new Firefox
version. I guess many people have already seen that happening, and
that's also the reason why Ubuntu has a custom Firefox add-on that
displays an information bar inside Firefox telling you to restart
your browser.
So the right way to do updates for software like this is to wait
until no Firefox instance is running on the machine. The easiest
time where this is guaranteed is actually during shutdown or boot.
I don't think Firefox is a good example for advocating offline updates.
Consider a routine update in the middle of a release cycle on a system
with open user sessions and running daemons.

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.

Michal Kubeček
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Philipp Wagner
2013-02-19 13:01:35 UTC
Permalink
Post by Michal Kubecek
You are talking about protecting the user from a potential application
crash after an update. But you forget to tell us that you are
It's usually not a crash, Firefox is just malfunctioning. So actually
offline updates would prevent the users from having a malfunctioning
(partly working) application. If instead the updates are applied on a
reboot during regular maintenance intervals (e.g. at 3am when nobody is
logged in), all users are better off.

Philipp
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Ruediger Meier
2013-02-19 14:25:27 UTC
Permalink
Post by Philipp Wagner
Post by Michal Kubecek
You are talking about protecting the user from a potential
application crash after an update. But you forget to tell us that
you are
It's usually not a crash, Firefox is just malfunctioning. So actually
offline updates would prevent the users from having a malfunctioning
(partly working) application. If instead the updates are applied on a
reboot during regular maintenance intervals (e.g. at 3am when nobody
is logged in), all users are better off.
Don't forget that there are a lot systems where users never log off or
where other important processes have to run 24/7. These systems are IMO
the more important ones.
So better fix existing online update issues instead of requiring a
reboot which is simply not possible to do in general. Then online
updates would also work on systems where offline updates are
possible ...

BTW firefox is really a bad example to satisfy offline updates because
usually it is malfunctioning very often in cause of many other reasons.
So no user would wonder about it.
Or "help" your users by doing ...
$ killall -11 firefox
... still less annoying than asking them for reboot.

cu,
Rudi
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Christian Boltz
2013-02-19 17:52:26 UTC
Permalink
Hello,
Post by Ruediger Meier
Post by Philipp Wagner
Post by Michal Kubecek
You are talking about protecting the user from a potential
application crash after an update. But you forget to tell us that
It's usually not a crash, Firefox is just malfunctioning. So
Don't forget that there are a lot systems where users never log off or
where other important processes have to run 24/7. These systems are
IMO the more important ones.
Agreed, rebooting is not the solution (except for kernel updates ;-)
Post by Ruediger Meier
BTW firefox is really a bad example to satisfy offline updates because
usually it is malfunctioning very often in cause of many other
reasons. So no user would wonder about it.
Or "help" your users by doing ...
$ killall -11 firefox
... still less annoying than asking them for reboot.
*lol*

Some mails up, I read that ubuntu ships a firefox extension that asks
the user to restart firefox after an update. Couldn't we just "steal"
this extension? ;-)


If I may add another wish/idea - it would be nice if I could just do
something like
zypper ps | systemctl restart --stdin
or, alternative implementation,
zypper ps --restart
;-)


Oh, BTW: I'm even zypper dup'ing to the latest Factory while working in
KDE. I don't say it always works without problems (but the problems I
remember were a) small and b) rare), and it causes significantly less
annoyance that waiting for a Factory update on shutdown.


Regards,

Christian Boltz
--
Also nochmals bitte Entschuldigung an alle procmail-Fans! Ich denke man
muß sich für ein Tool entscheiden, und muß halt dann alle Features und
Bugs in Kauf nehmen; also so ähnlich wie bei Frauen ... ;-)
[Ralph Müller in suse-linux]
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Wolfgang Rosenauer
2013-02-19 18:50:02 UTC
Permalink
Post by Christian Boltz
Hello,
Post by Ruediger Meier
Post by Philipp Wagner
Post by Michal Kubecek
You are talking about protecting the user from a potential
application crash after an update. But you forget to tell us that
It's usually not a crash, Firefox is just malfunctioning. So
Don't forget that there are a lot systems where users never log off or
where other important processes have to run 24/7. These systems are
IMO the more important ones.
Agreed, rebooting is not the solution (except for kernel updates ;-)
Post by Ruediger Meier
BTW firefox is really a bad example to satisfy offline updates because
usually it is malfunctioning very often in cause of many other
reasons. So no user would wonder about it.
Or "help" your users by doing ...
$ killall -11 firefox
... still less annoying than asking them for reboot.
*lol*
Some mails up, I read that ubuntu ships a firefox extension that asks
the user to restart firefox after an update. Couldn't we just "steal"
this extension? ;-)
I've looked into that extension years ago. It relies on some apt/dpkg
feature though.
...
and looking into the current version ...

It's working differently now and we might be able to "fork" that code
and add it to our openSUSE extension.
It is some hours work though to adapt (extract and integrate) it to our
extension. I'm not sure when I'll have time for that.

If anyone with some knowledge about JavaScript and Mozilla Addons would
like to give it a try I'll happily help as far as I can.


Wolfgang
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michal Kubecek
2013-02-20 11:25:20 UTC
Permalink
Post by Philipp Wagner
It's usually not a crash, Firefox is just malfunctioning. So
actually offline updates would prevent the users from having a
malfunctioning (partly working) application.
By shutting it down completely. And by shutting it down even in the case
when Firefox isn't actually updated at all.
Post by Philipp Wagner
If instead the updates
are applied on a reboot during regular maintenance intervals (e.g.
at 3am when nobody is logged in), all users are better off.
I guess we should start with making clear what users we are actually
talking about. I guess users running Firefox via "ssh -X" or from
a traditional X terminal are not the use case we should tailor our
solution to. The user logging into KDE/Gnome and running an update from
there is not a problem - he knows to run "zypper ps" (and zypper
actually tells him to do so when it is needed) and can decide what to do
according to the result.

So when we are talking about users and their running application, my
understanding always was that we are talking about the case when a
desktop is shared by a bunch of users who log into a desktop environment
of their choice and rather then logging out, they just lock the session
so that another user can come and switch to his session or start a new
one.

And I really don't see any advantage of offline updates in this case.
With this setup, to be able to reboot without shutting down all sessions
(except mine), I would have to ask all users to log out first. Which is
not easy to achieve and I would certainly prefer to avoid it when
possible and reboot such system only when I really need to.

Michal Kubeček
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Andrey Borzenkov
2013-02-20 14:57:13 UTC
Permalink
В Wed, 20 Feb 2013 12:25:20 +0100
Post by Michal Kubecek
solution to. The user logging into KDE/Gnome and running an update from
there is not a problem - he knows to run "zypper ps" (and zypper
actually tells him to do so when it is needed) and can decide what to do
according to the result.
No, you are wrong here. Typical user does not even know how to start
command line, and of course is not aware of "zypper" or how to
understand "zypper ps" output. Subscribers to -devel lists are in no
way typical users.

So for a desktop targeted at typical user offline update is the least
evil solution. Let's face it - there are no resources to guarantee
error-free online updates under any combination of installed software
and its configuration. And desktop users did reboot to install updates
for quite some time, so there is nothing new here. The best thing that
can be done here is what Solaris did for years with Live Update.
Prepare clone of current system, update it and reboot.

Of course technical savvy server admins should have a choice. No
question. But again - 24x7 is *NOT* something that can be achieved with
single system. Period. If you *really* need 24x7 you have to build high
available system where applications can be moved over to allow
maintenance work on a node. At which point there is no practical
argument against offline updates.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michal Kubecek
2013-02-20 15:22:50 UTC
Permalink
Post by Andrey Borzenkov
No, you are wrong here. Typical user does not even know how to start
command line, and of course is not aware of "zypper" or how to
understand "zypper ps" output. Subscribers to -devel lists are in no
way typical users.
It may be true but it doesn't change anything. Whether you use zypper,
YaST module or some other graphic tool, this can work the same.
Post by Andrey Borzenkov
So for a desktop targeted at typical user offline update is the least
evil solution.
As I explained, it's not. Offline update is never less annoying or less
intrusive and quite often it is more annoying and more intrusive.
Post by Andrey Borzenkov
Let's face it - there are no resources to guarantee
error-free online updates under any combination of installed software
and its configuration.
By the same logic we would have to stop trying to release a distribution
as it never can be guaranteed to be error-free. And, of course, an
offline update can never be guaranteed to be error-free either.
Post by Andrey Borzenkov
And desktop users did reboot to install updates for quite some time,
so there is nothing new here.
Windows users have been but this is their problem and problem of MS.
I definitely don't want to throw away advantages of linux systems just
because windows users are used to not having them.
Post by Andrey Borzenkov
But again - 24x7 is *NOT* something that can be achieved with
single system. Period. If you *really* need 24x7 you have to build high
available system where applications can be moved over to allow
maintenance work on a node. At which point there is no practical
argument against offline updates.
No idea why are you bringing this here. I wasn't talking about 24x7 or
high availability. Just about desktop users using the feature of having
more than one session open and switching between them - which is a
standard feature we offer and provide a comfortable user interface for.
And with memory prices being what they are, this scenario is likely to
get more and more common.

Michal Kubeček
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-20 18:37:48 UTC
Permalink
Post by Michal Kubecek
Post by Andrey Borzenkov
But again - 24x7 is *NOT* something that can be achieved with
single system. Period. If you *really* need 24x7 you have to build high
available system where applications can be moved over to allow
maintenance work on a node. At which point there is no practical
argument against offline updates.
No idea why are you bringing this here. I wasn't talking about 24x7 or
high availability. Just about desktop users using the feature of having
more than one session open and switching between them - which is a
standard feature we offer and provide a comfortable user interface for.
And with memory prices being what they are, this scenario is likely to
get more and more common.
Yeah, in fact, it happens a lot at home, and everything you say is
true: I have a hard time finding a way to "politely" reboot (ie:
without killing everyone else's session).
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Ken Schneider - openSUSE
2013-02-20 20:14:38 UTC
Permalink
Post by Claudio Freire
Post by Michal Kubecek
Post by Andrey Borzenkov
But again - 24x7 is *NOT* something that can be achieved with
single system. Period. If you *really* need 24x7 you have to build high
available system where applications can be moved over to allow
maintenance work on a node. At which point there is no practical
argument against offline updates.
No idea why are you bringing this here. I wasn't talking about 24x7 or
high availability. Just about desktop users using the feature of having
more than one session open and switching between them - which is a
standard feature we offer and provide a comfortable user interface for.
And with memory prices being what they are, this scenario is likely to
get more and more common.
Yeah, in fact, it happens a lot at home, and everything you say is
without killing everyone else's session).
And why are we trying to make linux into MS windows in regards to a
reboot every time a package gets an update? Why not instead teach users
how to use 'zypper ps' to check which processes need to be restarted amd
how to restart them. I never reboot except for kernel updates as there
is no need.
--
Ken Schneider
SuSe since Version 5.2, June 1998
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Dimstar / Dominique Leuenberger
2013-02-20 20:19:21 UTC
Permalink
This post might be inappropriate. Click to display it.
Claudio Freire
2013-02-20 22:14:57 UTC
Permalink
On Wed, Feb 20, 2013 at 5:19 PM, Dimstar / Dominique Leuenberger
Post by Dimstar / Dominique Leuenberger
Post by Ken Schneider - openSUSE
Post by Claudio Freire
Yeah, in fact, it happens a lot at home, and everything you say is
without killing everyone else's session).
And why are we trying to make linux into MS windows in regards to a
reboot every time a package gets an update? Why not instead teach users
how to use 'zypper ps' to check which processes need to be restarted amd
how to restart them. I never reboot except for kernel updates as there
is no need.
Guys,, really.. this thread is getting out of control and really boring
to read!
offline-updates is an OPTION! Nobody (I repeat: NOBODY) forces you to
use it... if you wish to do so: use zypper.. or if you wish: use rpm.
you prefer yast? Go for it! Or better Apper? be my guest! Or shall it
be gpk-applications? Then by all means! BUT GET YOUR LIFE TOGETHER and
choose your option.
No, it's not about that. You're bored because you don't understand
what the discussion is about. It's about what unkowledgable users are
offered by the default update app.

Why offer them a reboot process when none is necessary? Is that
correct? Can it be improved?

Some people argue the very risk of malfunctioning apps is undesirable,
where others (me included) prefer to minimize that risk, but still
maximize the number of updates that can be applied without such a
reboot.

I agree, if an average user is faced with such failures as they happen
with apps broken by online updates, they'd be very confused and would
infer linux to be unstable. So yes, it has to be safe. But many
updates are marked as requiring a reboot or relogin, so we are
discussing the possibility to transfer that knowledge to gnome's
updater, packagekit or whatever.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-20 20:28:06 UTC
Permalink
Post by Ken Schneider - openSUSE
And why are we trying to make linux into MS windows
That is not a technical argument, stop making silly appeals to emotion.

It does not matter if it is similar to DOS or solaris either, the only
thing that matter is if it works or not.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Ken Schneider - openSUSE
2013-02-20 20:53:17 UTC
Permalink
Post by Cristian Rodríguez
Post by Ken Schneider - openSUSE
And why are we trying to make linux into MS windows
Stop taking things out of context!
Why are we requiring a reboot every time a package gets an update?
Is that more technical for you!
Post by Cristian Rodríguez
That is not a technical argument, stop making silly appeals to emotion.
Having to restart my computer after every update IS a technical argument
because IT IS NOT NEEDED!
Post by Cristian Rodríguez
It does not matter if it is similar to DOS or solaris either, the only
thing that matter is if it works or not.
You seem to forget about choice, quite often. And I'm not referring to
choice of distro but how my distro of choice works!
--
Ken Schneider
SuSe since Version 5.2, June 1998
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Bruce Ferrell
2013-02-18 16:33:55 UTC
Permalink
Post by Cristian Rodríguez
Post by Ruediger Meier
Post by Michael Catanzaro
I notice that in 12.3 "Install Updates & Restart" now frequently
appears on the GNOME shell menu as per
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates
Isn't this a step backwards? I always do updates online and reboot only
on kernel updates (if I find it's worth to run the new kernel
immediately). Never had serious issues.
No. it is an step to sanity :-)
No, it's a step to windows like operation
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-18 16:52:05 UTC
Permalink
Post by Bruce Ferrell
No, it's a step to windows like operation
Well .. yeah.. feel free to propose other solution that also covers
applications crashing or misbehaving because an update is running.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-18 16:59:53 UTC
Permalink
On Mon, Feb 18, 2013 at 1:52 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Post by Bruce Ferrell
No, it's a step to windows like operation
Well .. yeah.. feel free to propose other solution that also covers
applications crashing or misbehaving because an update is running.
zypper ps
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.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-18 17:04:57 UTC
Permalink
On Mon, Feb 18, 2013 at 1:59 PM, Cristian Rodríguez
On Mon, Feb 18, 2013 at 1:52 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Post by Bruce Ferrell
No, it's a step to windows like operation
Well .. yeah.. feel free to propose other solution that also covers
applications crashing or misbehaving because an update is running.
zypper ps
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).
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-18 17:14:18 UTC
Permalink
Post by Claudio Freire
On Mon, Feb 18, 2013 at 1:59 PM, Cristian Rodríguez
On Mon, Feb 18, 2013 at 1:52 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Post by Bruce Ferrell
No, it's a step to windows like operation
Well .. yeah.. feel free to propose other solution that also covers
applications crashing or misbehaving because an update is running.
zypper ps
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.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-18 17:22:31 UTC
Permalink
On Mon, Feb 18, 2013 at 2:14 PM, Cristian Rodríguez
Post by Claudio Freire
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+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Cristian Rodríguez
2013-02-18 17:31:19 UTC
Permalink
Post by Claudio Freire
It needs two restarts, so it's quite unacceptable when updating a
minor component of the system.
zypper up will always be an option..
Post by Claudio Freire
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.
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-18 17:38:22 UTC
Permalink
On Mon, Feb 18, 2013 at 2:31 PM, Cristian Rodríguez
Post by Cristian Rodríguez
Post by Claudio Freire
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+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Andreas Schwab
2013-02-19 08:50:15 UTC
Permalink
Post by Claudio Freire
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.

Andreas.
--
Andreas Schwab, SUSE Labs, ***@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Ruediger Meier
2013-02-19 10:17:43 UTC
Permalink
Post by Cristian Rodríguez
Post by Claudio Freire
It needs two restarts, so it's quite unacceptable when updating a
minor component of the system.
zypper up will always be an option..
Post by Claudio Freire
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+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michael Catanzaro
2013-02-18 23:09:22 UTC
Permalink
Post by Cristian Rodríguez
The "Offline System Updates" feature does *exactly* what is needed and
was probably designed by someone who underwent all the upgrade pains :-)
If you use Fedora 18 for any length of time, you'll start to agree with
Claudio that double-restarting for small updates kind of sucks.
(Especially when you have a long LUKS passphrase to type twice!) So
while the current implementation is a nice start, I do think it needs
ironed-out rather a lot...
Post by Cristian Rodríguez
We just need to make it work in openSUSE.
Back to my original question:

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

2) If not, should we maybe patch GNOME Shell to hide this option for the
time being?
Dominique Leuenberger
2013-02-18 23:20:53 UTC
Permalink
Post by Michael Catanzaro
1) Does it work for anyone *right now*?
No: we do not start / enable the systemd services needed for this by
default.
Post by Michael Catanzaro
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+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Michael Catanzaro
2013-02-19 04:01:13 UTC
Permalink
Post by Dominique Leuenberger
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.

(What to do?)
Dominique Leuenberger a.k.a. Dimstar
2013-02-19 08:58:12 UTC
Permalink
Post by Michael Catanzaro
Post by Dominique Leuenberger
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
[ 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+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Dominique Leuenberger a.k.a. Dimstar
2013-02-19 09:38:24 UTC
Permalink
Post by Dominique Leuenberger a.k.a. Dimstar
Post by Michael Catanzaro
Post by Dominique Leuenberger
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
[ 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.
Fix submitted to GNOME:Factory for review: SR#155782. The patch has
already been merged upstream.

Dominique
--
To unsubscribe, e-mail: opensuse-factory+***@opensuse.org
To contact the owner, e-mail: opensuse-factory+***@opensuse.org
Claudio Freire
2013-02-19 17:10:58 UTC
Permalink
On Tue, Feb 19, 2013 at 6:38 AM, Dominique Leuenberger a.k.a. Dimstar
Post by Dominique Leuenberger a.k.a. Dimstar
Post by Michael Catanzaro
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 :^)
Post by Dominique Leuenberger a.k.a. Dimstar
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?
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
Joschi Brauchle
2013-02-19 12:04:13 UTC
Permalink
Post by Cristian Rodríguez
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.
I would like to add something to the discussion here:

I am currently using a bash script that does the following:
1) Walk thru all available patches shown by "zypper lp" and figure out
the affected RPMs (zypper -q -n if -t patch $PATCH)
2) Get a list of all files included in the currently installed version
of an RPM to be upgraded (rpm -ql $PACKAGE)
3) Grep the output "lsof" with the list of files from above.
4) If none of the files of all RPMs affected by a particular patch are
currently in use, flag this patch as "safe to install"
5) Install all patches with "zypper -n in -t patch" that were flagged
"safe to install".
6) Notify the logged in users (via email in our case) if there are any
patches left which cannot be installed, as the affected files are in
use. As our users are quite technically skilled, tell them the list of
affected files and let them decide to logout/reboot and install manually.

Using this script I managed to update all system components that are
currently not in use and I notify the user only if he really needs to
take action. I am not blindly installing all available patches, possibly
creating problems for running applications.


This has worked quite nicely until now. Problems have occured with
kernel upgrades (as the kernel and its modules may not be shown in
lsof), hence I now exclude all patches that have the "Reboot Required:
Yes" set from the "zypper lp" list.


-J Brauchle
Loading...