https://bugzilla.novell.com/show_bug.cgi?id=540587
https://bugzilla.novell.com/show_bug.cgi?id=540587#c20
L. A. Walsh changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |suse@tlinx.org
Component|YaST2 |Upgrade Problems
Resolution|WONTFIX |
AssignedTo|ma@suse.com |bnc-team-screening@forge.pr
| |ovo.novell.com
Product|openSUSE 11.1 |openSUSE 13.1
Severity|Critical |Normal
--- Comment #20 from L. A. Walsh 2014-01-15 11:19:59 PST ---
Given that this was marked, minimally for 'need to document',
But really was "addressed", indirectly(?) by configuring all packages to
download before starting.
Also, of note -- there is no reason to shut down squid -- ANY more so,
than to kill off any program that has files that are "in use". I.e.
Right now(in 13.1), if I update something, I can run "zypper ps" AFTER
an update has finished, that will tell me which files are currently being
used by running procs that are 'deleted' (i.e. likely replaced by the update
that just occurred). This means there are a bunch of programs & services that
are NOT automatically halted when one of their files is updated.
If you update vim -- would you expect all sessions with vim to be killed off
(and hopefully restarted?) as part of the upgrade? Why do this w/squid -- i.e.
inconsistent behavior that wouldn't likely be expected because the user is
likely to have experience
You don't want to shut down existing, working services which are working in the
middle of a user session -- especially since service upgrades can cause
config-file incompatibilities.
Possible actions:
1) Verify that the system state is consistent before restarting the service, so
if the restart causes the upgrade to "halt", the user will still have a working
system. Note: not ideal, as the user may have updates running on multiple
systems and be leaving for a 'long break' (overnight or such, as they are
expecting the update to take some time), and they would have to repeat the
update in order to continue it. Could be addressed by methods used during
initial install after reboot to complete further setup after a reboot.
2) Check users upgrade sourced and see if it will be affected by the step --
network (drivers, squid, "ssh if updating via remote login", socks(dante)...),
or local device (replacing a driver or restarting a service used to access the
device (i.e. update source on a remote network location, or a cd-driver, or a
usb-device or a user-space-device driver). This would be *complicated* for
little gain and is merely a way of seeing if a restart of a service 'should be
safe' -- if it is not, some other action is needed to ensure that.
3) In case of something like squid, verify that the new config WILL work (squid
will restart), and that the setup-engine can seamlessly *reconnect* to reopen
the needed repos -- would be likely w/http, less likely with https if some
accss check is needed. Other fail examples: stateful NFS vs. stateless,
reconfigured samba...etc...
4) Just don't restart the service -- leave that to the user just like zypper
doesn't kill off processes using files that are upgraded. They can use "zypper
ps" to determine what needs to be restarted.
---
a **workaround** that is available, is the option to download the sources to
stable local sources (useful by default if usr has option set to save/cache
downloaded packages locally).
----------
Am re-opening this, since 1, it was closed as resolved+rejected meaning the bug
was invalid or nothing is going to be done about it. Minimally, a workaround
is provided, so resolved or closed+feature providing workaround would be more
appropriate.
Note, the workaround doesn't really solve the base problem of doing something
during update that invalidates a source you are updating from (networks, likely
being the most vulnerable -- and ALSO, **importantly**, one of the most used
methods as it allows downloading only needed updates (vs. an ISO which will
download a bunch of things a user may not need).
As such, the bug might be reassigned to an update team for eventual handling
(GSoC?) or such. It's not a high priority for me as I 99.99% of the time
don't use a full product upgrade anymore as it's too likely to fail or break my
system and leave it (and me) offline for a long period until it is fixed (my
suse system is my gateway to the internet, as well as a data server for all of
my other non-linux machines (like windows desktops). If server is down --
everything halts.
Lowered importance from critical to normal as a workaround is available
(predownload).
Listed product as suse 13.1 (current version) as this is still an issue, but
left platform as 11.1 since that is where it was originally reported.
Changed category to 'Update problems', as that is more appropriate than yast.
If it is unlikely this will ever be fixed, please close w/correct resolution
(which I think would "resolved/feature", as referring to the workaround, though
not thinking that is "strictly" used for workarounds (maybe it is, but doubt
it).
As noted above, this is not a high priority issue for me personally, as since
an upgrade fiasco in going to 11.3, I realized I needed to not try "all at
once" upgrades unless I didn't care about all of my systems being out of
commission for some unknown amount of time (was online w/in a week, but I was
still fixing and repairing found problems 4 months later) :-(.
FWIW -- I think more work should be put into supporting piecemeal upgrades and
intercompat between versions **where possible**...
(but that's another whole issue)...
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.