[Bug 540587] New: If Yast MUST NOT kill SQUID in middle of system update!
http://bugzilla.novell.com/show_bug.cgi?id=540587 Summary: If Yast MUST NOT kill SQUID in middle of system update! Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86-64 OS/Version: openSUSE 11.1 Status: NEW Severity: Critical Priority: P5 - None Component: YaST2 AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: suse@tlinx.org QAContact: jsrain@novell.com Found By: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 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. However I was doing a Factory update. That just happened to include squid this time. About half way through a 500MB download/update it suddenly lost its connection -- and hung. Restarting squid didn't help. It was dead and required restart -- at which point trying to redo the factory update was futile -- it thought everything was done -- BUT the configuration of every service it updated was *wiped* and set to 'off'. I'm having to go through each service as I find which ones it killed and wiped and reconfig or at least restart them. But in a few cases, the config files have been reinitialized to non-workable values. Examples: xinetd was setup with no tcpmux builtin configure, so installed services like vnc generated errors because the standard vnc-server needs TCPMUX. The arpwatchd was no longer looking on my inside net, but on my outside and talking about bogons because it lost it's local group list. It also was no longer in its own group. named is now generating messages about not having write access to its working directory (don't know if this is a new message, or something was changed). The squid startup script was replaced and the old one wasn't saved -- I had it set to filter some common error messages (restored from an edit backup). Might be a few others -- several services were just 'stopped (chkconfiged 'off') when they had been on. Have yet to do an exhaustive search for problems, as I'm still in firefighting mode. But Yast really needs to be smart enough to check, if it is using a proxy server, AND proxy server is on same system, it needs to be "very circumspect about restarting it (if it should restart it at all, maybe it should ask user or wait for reboot?)...but if it closed all connections and was sure it would restart, then it could auto-restart it just like when log-rotation happens periodically. Marking this Critical, as it has cost a large amount of time to recover from this (still in progress).... and did lose some data (though I probably have earlier backups I could restore from, I'm taking opportunity to recheck configs. I am noticing some (1-2?) incompatible config files with the new versions that were installed. Will try to remember to file more bugs later...but filing bugs takes me away from fixing, and my email is another service that is broken right now. (was trying to fix some configuration problem and I've made things worse! --- ;^) so what else is new...but if it hadn't been broken in the first place, I probably wouldn't have been mucking w/it!...but hey, it *is* a learning experience, so I'm not "angry", more like 'annoyed'...and wanting to create this bug as a notice of the problem. Reproducible: Didn't try Steps to Reproduce: 1. have "alot" of updates (I didn't see all the updates -- it autoselected "A bunch" more than I had picked out...(as usual ;^/ )...dependency hell! 2. I was updating through a proxy server (squid) running on the machine being updated -- I didn't explicitly ask yast todo this, it just took the values from my environment vars (HTTP_PROXY & such)... 3. One of the packages updated, "apparently" was squid...right in the middle of the updates. It left my system in an inconsistent and ill-or-unconfiged state with many serviced turned off (that had been on ). Actual Results: System way messed up. Expected Results: Normal factory upgrade. -- 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 rszhu@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c1
zhu rensheng
http://bugzilla.novell.com/show_bug.cgi?id=540587
Lukas Ocilka
http://bugzilla.novell.com/show_bug.cgi?id=540587
Michael Schröder
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
http://bugzilla.novell.com/show_bug.cgi?id=540587
User coolo@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c3
Stephan Kulow
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
http://bugzilla.novell.com/show_bug.cgi?id=540587
User aj@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c5
Andreas Jaeger
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
http://bugzilla.novell.com/show_bug.cgi?id=540587
Stephan Kulow
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
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#c8
Karl Eichwalder
should we make the release notes really a "things to note when you zypper dup"? I would think this should be split.
Yeah. Basic info about "zypper dup" is already in the manual (11.2)--see the section about zypper and the update chapter. I think for the moment this should go into the release notes. The books are already locdrop'ed (sent to Dublin for translation). -- 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
http://bugzilla.novell.com/show_bug.cgi?id=540587
User aj@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c10
Andreas Jaeger
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
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 suse@tlinx.org added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c12
L. A. Walsh
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
http://bugzilla.novell.com/show_bug.cgi?id=540587
User suse@tlinx.org added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c14
--- Comment #14 from L. A. Walsh
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
http://bugzilla.novell.com/show_bug.cgi?id=540587
User suse@tlinx.org added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c16
--- Comment #16 from L. A. Walsh
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.
There are some differences in the situations you describe. 1) if one is updating a large list of interdependent packages, and downloading as one is installing (which appeared to be the default action(?)) while executing 'yast'(GUI), then one is guaranteed to have a problem if one kills off the network. 2) If it's an update to a released product, it would violate expectations for an incompatible change to be introduced as a patched or updated product. You could make your argument if one was performing a live-upgrade to the next level of product -- in that case, all RPMS needed to perform the upgrade should likely be downloaded ahead of time, and critical packages saved for 'last' where they would be less likely to disrupt the installation. Usually, if incompatible changes are made to config files between _upgrades_ (going between versions), those packages need to be moved last if they are critical to the process AND if the user has modified one of the config files. If the config files are in the standard state (unmodified), it should be safe to upgrade that package with its upgraded options. If it's not, then that's a bug in that product. This bug's not about all bugs in all products. It's about not killing off your network infrastructure while you are still using it to download updates that are being interspersed with installs AND to "be careful" about updating packages that are being used as 'infrastructure' so that when a daemon (like squid, in _this_ situation) is restarted, the update process is in a known, idle state so a temporarily dropped connection won't cause a hang, bug can be immediately re-initiated after the package has been _updated_ (within the same release). In the case of squid -- if the update or upgrade process detects it is using a proxy on the same machine that's being updated, it might be prudent to issue a warning and ask if this is intentional -- especially if the proxy is going to be replaced. -- 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
http://bugzilla.novell.com/show_bug.cgi?id=540587
http://bugzilla.novell.com/show_bug.cgi?id=540587#c
Hendrik Vogelsang
http://bugzilla.novell.com/show_bug.cgi?id=540587
http://bugzilla.novell.com/show_bug.cgi?id=540587#c18
Roman Drahtmueller
http://bugzilla.novell.com/show_bug.cgi?id=540587
http://bugzilla.novell.com/show_bug.cgi?id=540587#c19
Michael Andres
https://bugzilla.novell.com/show_bug.cgi?id=540587
https://bugzilla.novell.com/show_bug.cgi?id=540587#c20
L. A. Walsh
https://bugzilla.novell.com/show_bug.cgi?id=540587
https://bugzilla.novell.com/show_bug.cgi?id=540587#c
zhang jiajun
https://bugzilla.novell.com/show_bug.cgi?id=540587
https://bugzilla.novell.com/show_bug.cgi?id=540587#c21
Arvin Schnell
https://bugzilla.novell.com/show_bug.cgi?id=540587
https://bugzilla.novell.com/show_bug.cgi?id=540587#c22
Roman Drahtmueller
https://bugzilla.novell.com/show_bug.cgi?id=540587
https://bugzilla.novell.com/show_bug.cgi?id=540587#c23
Michael Andres
https://bugzilla.novell.com/show_bug.cgi?id=540587
https://bugzilla.novell.com/show_bug.cgi?id=540587#c24
--- Comment #24 from L. A. Walsh
participants (1)
-
bugzilla_noreply@novell.com