https://bugzilla.novell.com/show_bug.cgi?id=540587 https://bugzilla.novell.com/show_bug.cgi?id=540587#c20 L. A. Walsh <suse@tlinx.org> 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 <suse@tlinx.org> 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.