On Wed, Sep 30, 2009 at 11:00:13PM +0400, croco_at_private wrote: > I tried all this, and finally installed all the stuff successfully. After > that (and after configuring the Apache conf files) I got the following: > > varan101!root:~# apachectl start > *** glibc detected *** free(): invalid pointer: 0x800c0ae8 *** > /usr/sbin/apachectl: line 102: 5692 Aborted $HTTPD > $OPTIONS -k $ARGV Ouch. This made me curious enough that I went ahead and installed the packages myself. While at it, I learned an even easier way to resolve the dependencies. With rpmdb-CentOS installed on Owl (and nothing else installed yet), I get: bash-3.1# rpm -Uvh httpd-2.0.52-41.ent.4.centos4.i386.rpm error: Failed dependencies: /etc/mime.types is needed by httpd-2.0.52-41.ent.4.centos4 apr >= 0.9.4-24.2 is needed by httpd-2.0.52-41.ent.4.centos4 httpd-suexec is needed by httpd-2.0.52-41.ent.4.centos4 libapr-0.so.0 is needed by httpd-2.0.52-41.ent.4.centos4 libaprutil-0.so.0 is needed by httpd-2.0.52-41.ent.4.centos4 libdb-4.2.so is needed by httpd-2.0.52-41.ent.4.centos4 libexpat.so.0 is needed by httpd-2.0.52-41.ent.4.centos4 libgssapi_krb5.so.2 is needed by httpd-2.0.52-41.ent.4.centos4 libk5crypto.so.3 is needed by httpd-2.0.52-41.ent.4.centos4 libkrb5.so.3 is needed by httpd-2.0.52-41.ent.4.centos4 liblber-2.2.so.7 is needed by httpd-2.0.52-41.ent.4.centos4 libldap-2.2.so.7 is needed by httpd-2.0.52-41.ent.4.centos4 Suggested resolutions: /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/apr-0.9.4-24.9.i386.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/apr-util-0.9.4-22.el4.i386.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/db4-4.2.52-7.3.el4.i386.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/expat-1.95.7-4.i386.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/httpd-suexec-2.0.52-41.ent.4.centos4.i386.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/krb5-libs-1.3.4-62.el4.i386.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/mailcap-2.1.17-1.noarch.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/openldap-2.2.13-12.el4.i386.rpm Notice the "Suggested resolutions" part, which did not appear without rpmdb-CentOS. Downloading and adding those packages to the line, I get: rpm -Uvh httpd-2.0.52-41.ent.4.centos4.i386.rpm apr-0.9.4-24.9.i386.rpm apr-util-0.9.4-22.el4.i386.rpm expat-1.95.7-4.i386.rpm httpd-suexec-2.0.52-41.ent.4.centos4.i386.rpm krb5-libs-1.3.4-62.el4.i386.rpm mailcap-2.1.17-1.noarch.rpm openldap-2.2.13-12.el4.i386.rpm which prints: error: Failed dependencies: libdb-4.2.so is needed by httpd-2.0.52-41.ent.4.centos4 libdb-4.2.so is needed by apr-util-0.9.4-22.el4 cyrus-sasl is needed by openldap-2.2.13-12.el4 cyrus-sasl-md5 is needed by openldap-2.2.13-12.el4 libsasl2.so.2 is needed by openldap-2.2.13-12.el4 Suggested resolutions: /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/cyrus-sasl-2.1.19-14.i386.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/cyrus-sasl-md5-2.1.19-14.i386.rpm /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/db4-4.2.52-7.3.el4.i386.rpm So I download these three, and add cyrus-sasl and cyrus-sasl-md5 to the line (not yet db4 because Owl-current already has newer db4, so it needs special handling). This reduces the "complaints" to just: error: Failed dependencies: libdb-4.2.so is needed by httpd-2.0.52-41.ent.4.centos4 libdb-4.2.so is needed by apr-util-0.9.4-22.el4 Suggested resolutions: /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/db4-4.2.52-7.3.el4.i386.rpm Time to deal with db4. I install it with: bash-3.1# rpm -ivh --force db4-4.2.52-7.3.el4.i386.rpm warning: db4-4.2.52-7.3.el4.i386.rpm: V3 DSA signature: NOKEY, key ID 443e1821 Preparing... ########################################### [100%] 1:db4 ########################################### [100%] Please note that at this point we have two versions of db4 installed - Owl-current's newer version and CentOS' older one. This is not a downgrade, just two versions of db4 at once. That's one of the rare cases/exceptions where rpm's "-i" option is desirable. Also note that I did not bother installing the CentOS GnuPG key; if this were not a test environment only, the key would better be installed. Finally, with the older version of db4 in place, the rest installs: bash-3.1# rpm -Uvh httpd-2.0.52-41.ent.4.centos4.i386.rpm apr-0.9.4-24.9.i386.rpm apr-util-0.9.4-22.el4.i386.rpm expat-1.95.7-4.i386.rpm httpd-suexec-2.0.52-41.ent.4.centos4.i386.rpm krb5-libs-1.3.4-62.el4.i386.rpm mailcap-2.1.17-1.noarch.rpm openldap-2.2.13-12.el4.i386.rpm cyrus-sasl-2.1.19-14.i386.rpm cyrus-sasl-md5-2.1.19-14.i386.rpm warning: httpd-2.0.52-41.ent.4.centos4.i386.rpm: V3 DSA signature: NOKEY, key ID 443e1821 Preparing... ########################################### [100%] 1:krb5-libs ########################################### [ 10%] 2:expat ########################################### [ 20%] 3:apr ########################################### [ 30%] 4:mailcap ########################################### [ 40%] 5:cyrus-sasl ########################################### [ 50%] 6:openldap ########################################### [ 60%] 7:apr-util ########################################### [ 70%] 8:httpd ########################################### [ 80%] 9:httpd-suexec ########################################### [ 90%] 10:cyrus-sasl-md5 ########################################### [100%] Now to reproduce "your" problem: bash-3.1# service httpd start Starting httpd: httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName *** glibc detected *** free(): invalid pointer: 0xb942c6d8 *** /etc/rc.d/init.d/functions: line 34: 30087 Aborted start-stop-daemon $FLAGS --startas /bin/nice -- -n "$NICE" "$WHICH" $* Oops. Really nasty. Here's a guess: they have a bug in the CentOS 4 package(s), likely also present in the RHEL4 packages, but they are not running into it because their slightly older glibc (2.3.4'ish) does not check for this kind of errors yet (vs. our 2.3.6'ish). Let's disable killing of the process ("1" means "Generate an error message, but do not kill the program"): bash-3.1# MALLOC_CHECK_=1 service httpd start Lots of "*** glibc detected *** free(): invalid pointer" messages on httpd startup, but it does start up now. :-) Going to the server with a web browser, I get an empty directory listing with: Apache/2.0.52 (CentOS) Server at xxx.xxx.xxx.xxx Port 80 at the bottom. So Apache seems to work despite of those errors. Perhaps that's how it actually works on CentOS 4 and RHEL4 (I might report this to Red Hat, although reporting it in this way is weird). Now to stop it: bash-3.1# service httpd stop Stopping httpd: /etc/rc.d/init.d/functions: line 147: kill: d: invalid signal specification Oops. In /etc/rc.d/init.d/httpd, they have: killproc -d 10 $httpd Editing the file to remove "-d 10" makes the above command work just fine. We'll need to consider adding support for "-d" into the function on Owl, at least "dummy support" (ignore the option). To summarize: it is not very hard to identify, download, and install all of the needed packages, and even to get CentOS' httpd to work on Owl, but it does require knowledge/skills (note: that's not knowledge of specific Red Hat package names, with the only exception being rpmdb-*). Perhaps even more importantly, I would feel uncomfortable running httpd with now-known dynamic memory (de)allocation issues and with plenty of libraries that are irrelevant for my intended use. Thus, I'd use a custom build of Apache, perhaps installing it under /opt/apache/VERSION and pointing /opt/apache/current to there (this is Openwall's convention for local builds/installs that can be moved between similar systems). > As far as I understand, such a thing, happening to a well-tested stable > package, should mean a shared libraries incompatibility. Sort of, but not exactly. > At this point I > decided not to follow this way any further; fortunately all the things > happened within a OpenVZ container so that I could just shut down the VPS > and create another one from scratch. It would be too complicated to > reinstall the real machine, and it is tricky to restore the status quo > after lots of packages were installed and some of them even downgraded the > existing ones. Why "downgraded"? Please see my explanation regarding db4 above. It's not a downgrade. I agree that this behavior of CentOS' httpd is a reason to abandon it. > Errr... I continue to think it is a wastage of time to try making foreign > packages work under Owl. This might not be worth the time, but it is not exactly a waste of time. Having the option to install certain "foreign" packages is of some use. For example, when a client asks us to install Emacs on an Owl system where they have an account, we simply do: bash-3.1# rpm -Uvh emacs-* warning: emacs-common-21.3-19.EL.4.i386.rpm: V3 DSA signature: NOKEY, key ID 443e1821 Preparing... ########################################### [100%] 1:emacs-common ########################################### [ 50%] 2:emacs-nox ########################################### [100%] (OK, need to have the GnuPG key when doing it for real, or better yet pre-check the package files against a previously-checked copy.) So emacs-nox from CentOS 4 just installs on Owl, with no dependencies at all. Then it just works (run "emacs-nox" as a user on the system). We find this quite useful. > I should have spent this day compiling Apache > from the sources instead -- I think it could give me better results. Yes, but neither approach should be taking a day - more like an hour, at least now that you're aware of rpmdb-CentOS. > > Thank you for your testing, which happened to remind us of the db4 > > version issue. > > I don't think this 'issue' worth the time you're going to spend fixing it. You may be right. We might end up mentioning it in Owl/doc/REDHAT, along with the trivial workaround (above). Anyhow, we have identified a few issues due to your testing, and we have already improved the wiki content a little bit. Thanks! I wish others provided this sort of feedback (and criticism) as well (and did so on owl-users as well; we're in fact receiving more feedback in private). Alexander -- To unsubscribe, e-mail owl-users-unsubscribe_at_private and reply to the automated confirmation request that will be sent to you.Received on Thu Oct 01 2009 - 06:44:42 PDT
This archive was generated by hypermail 2.2.0 : Thu Oct 01 2009 - 06:45:19 PDT