http://bugzilla.novell.com/show_bug.cgi?id=540587 Lukas Ocilka changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|locilka@novell.com |mls@novell.com -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User ma@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c2 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |coolo@novell.com, | |ma@novell.com AssignedTo|zypp-maintainers@forge.prov |hvogel@novell.com |o.novell.com | --- Comment #2 from Michael Andres 2009-09-21 08:27:28 MDT --- With 11.2 you will be able to configure libzypp to download all packages before the installation is actually started - provided you have enough diskspace. If so, there's at least less risk that the installation fails and leaves your system in an inconsistent state. But those service restarts are triggered by the packages %pre/post scripts itself, not by yast. Dont't know if this can be done smoother. Assigning to the sqid maintainer. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User coolo@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c4 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|hvogel@novell.com |aj@novell.com --- Comment #4 from Stephan Kulow 2009-10-13 08:36:05 MDT --- I assign this action item to AJ, lack of time ;( -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User coolo@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c6 --- Comment #6 from Stephan Kulow 2009-10-13 09:30:46 MDT --- should we make the release notes really a "things to note when you zypper dup"? I would think this should be split. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User ke@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c7 Karl Eichwalder changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #7 from Karl Eichwalder 2009-10-19 03:46:42 MDT --- (In reply to comment #5)

Karl, please add the following to the release notes:

If you update with zypper dup, packages might get restarted during the process and it can happen that the restart does not succeed before you adjust the config files. This is especially critical if your system uses services needed for downloading the update, e.g. a local proxy (squid) on the machine you update.

Set commit.downloadMode = DownloadInAdvance in /etc/zypp/zypp.conf so that first everything is downloaded and then packages get installed. This needs enough space on the /var partition to hold all downloaded packages.

Afterwards, let's reassign to Henne for fixing squid.

Thanks for the draft! -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User ke@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c9 Karl Eichwalder changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO CC| |hvogel@novell.com, | |ke@novell.com Info Provider| |aj@novell.com --- Comment #9 from Karl Eichwalder 2009-10-22 00:31:19 MDT --- Reading the bug again, I think it is not about "zypper dup", but the usual online updates with yast (on 11.1). I'm not sure whether it is a yast or squid issue, though. Of course, we could document the new zypper config option nevertheless... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User suse@tlinx.org added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c11 --- Comment #11 from L. A. Walsh 2009-10-22 01:07:43 PDT ---

From first few of initial report...

I was doing a system update. Normally my web requests go through squid to take advantage of a large local (6GB) disk cache for various downloaded objects. However, >>>yast<< also pays attention to the global vars HTTP_PROXY and friends, and uses them during its operations. Normally not a problem. -------- I was running the GUI version of YaST -- the same would likely happen with zypper -- I mean they have to pay attention to the proxy, it just so happens if they are updating the proxy package AND it is running on the same machine, ... *cough*; *choke*. Probably need to check if running through a proxy, does proxy addr reverse DNS evaluate to the reverse DNS of the current machine?... That would have prevented my 'hiccup'..., but better would be to loop through all the interface addresses and see if any match the proxy in case I was using a name associated with a different interface ?? Is this the information you were looking for? Should be able to download squid, run the install, then restart it, then continue with downloading more packages....just have to be sure to not be downloading while squid is restarting. Ideally closing the connection ... doesn't usually take squid long to restart if there are no connections -- a few seconds. Should be able to update squid while it is running unless the update deletes the cache directory or something. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User ke@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c13 --- Comment #13 from Karl Eichwalder 2009-10-22 03:36:04 MDT --- I still think you did a manual on-line update to update your system ;) That's not what we normally call "system update" or "system upgrade". For sure, you did not call "zypper dup" or "zypper dist-upgrade". OTOH, the last squid update for 11.1 was this one (rather old): ------------------------------------------------------------------- Wed Feb 18 03:31:00 CET 2009 - crrodriguez@suse.de - fix CVE-2009-0478 [bnc#472834] ==================================================================== BTW, are you running squid or squid3? Are you really using 11.1? Or some kind of openSUSE:Factory? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User ma@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c15 --- Comment #15 from Michael Andres 2009-10-22 06:02:37 MDT --- - Comment #9: '..whether it is a yast or squid issue...' This is a potential problem whenever you update a package in a running system. It is not related to squid only. It is not related to dup only. It is not related to openSUSE only. If one of the components required to perfrom the update (rpm, aria, curl, bash, network, ..) breaks during the update, then you are stuck. The solver can check whether the packages dependencies are ok, but NOT if after the package update configfiles, package version and system settings still fit together. If you apply changes to a configfile and the package overwrites it, the service may fail because the options are missing. If the package does not overwrite your configfile, the service may fail because the options are no longer supported, or because some newly introduced option is now missing. Whatever you do it may fail. The more packages involved, the bigger the chance for something to break. And zypper dup performing a real distribution upgrade is a big transaction. - If you encourage people to set DownloadInAdvance when doing zypper dup to migrate from one openSUSE version to another, you should also tell them that they probably need really much diskspace. This kind of dup will probably update almost all installed packages. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 User ke@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c17 Karl Eichwalder changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ke@novell.com |hvogel@novell.com --- Comment #17 from Karl Eichwalder 2009-10-27 08:31:02 MDT --- For the release notes, I created Bug 550417. This is either a yast limitation or a squid issue, or both. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=540587 http://bugzilla.novell.com/show_bug.cgi?id=540587#c18 Roman Drahtmueller changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |draht@novell.com AssignedTo|rhaidl@novell.com |ma@novell.com --- Comment #18 from Roman Drahtmueller 2009-11-25 16:22:04 UTC --- Squid does not restart itself, it is being restarted. Can we agree that it is out of squid's scope and responsibility to determine if it is allowed to be restarted? After all, it doesn't care if it's used for downloading updates or surfing bugzilla.novell.com. Re-assigning from rhaidl@ to ma@. Thanks, Roman (new squid package maintainer) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

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.

https://bugzilla.novell.com/show_bug.cgi?id=540587 https://bugzilla.novell.com/show_bug.cgi?id=540587#c21 Arvin Schnell changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|yast2-maintainers@suse.de |poeml@cmdline.net --- Comment #21 from Arvin Schnell 2014-01-16 08:47:16 UTC --- Based on comment #19 reassigning to bugowner of squid. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=540587 https://bugzilla.novell.com/show_bug.cgi?id=540587#c23 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |313506 AssignedTo|ma@suse.com |draht@suse.com --- Comment #23 from Michael Andres 2014-01-16 11:57:30 CET --- @Roman: Well, first of all it's up to the package to determine if, when and how the service is restarted. You can e.g. move the service restart to out of %post into %posttrans, so it should be executed _after_ the complete package installation is done. If you do so, your bug will depend on bug #313506, because execution of %posttrans must be moved from within rpm into libzypp. This way we can actually guarantee, that those scripts are not executed too early by rpm (currently immediately after the packages %post scripts). This is targeted for 13.2. -- 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.