Apache2.0.50 und Suse 9.2
Hallo, nachdem Update von 9.1 auf 9.2 funktioniert Apache2 nicht mehr: [emerg] (38)Function not implemented: Couldn't create accept lock Deinstallieren und löschen aller Konfig-Dateien brachte keine Besserung. Nach etwas Umsehen im Netz gibt es folgenden Workaround: /etc/apache2/httpd.conf.local AcceptMutex fcntl Danach zeigt, das error_log: [debug] prefork.c(955): AcceptMutex: fcntl (default: pthread) Kernel: Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux Der Fehler trat auch beim Installationskernel, und den weiteren Updates auf. Irgendwie habe ich den Eindruck, daß das so nicht richtig ist. Wer weiß näheres? Grüße Andreas
On Wed, Dec 01, 2004 at 10:39:27AM +0100, Andreas Ernst wrote:
Hallo,
nachdem Update von 9.1 auf 9.2 funktioniert Apache2 nicht mehr:
[emerg] (38)Function not implemented: Couldn't create accept lock
Deinstallieren und löschen aller Konfig-Dateien brachte keine Besserung.
Nach etwas Umsehen im Netz gibt es folgenden Workaround:
/etc/apache2/httpd.conf.local
AcceptMutex fcntl
Danach zeigt, das error_log:
[debug] prefork.c(955): AcceptMutex: fcntl (default: pthread)
Kernel:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der Fehler trat auch beim Installationskernel, und den weiteren Updates auf.
Irgendwie habe ich den Eindruck, daß das so nicht richtig ist. Wer weiß näheres?
Da sind wohl teilweise noch alte Pakete installiert. rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1 Schau auch mal nach folgendem: rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686 Peter
Hallo Peter, danke für Deine Antwort. poeml@cmdline.net schrieb:
On Wed, Dec 01, 2004 at 10:39:27AM +0100, Andreas Ernst wrote:
Hallo,
nachdem Update von 9.1 auf 9.2 funktioniert Apache2 nicht mehr:
[emerg] (38)Function not implemented: Couldn't create accept lock
Deinstallieren und löschen aller Konfig-Dateien brachte keine Besserung.
Nach etwas Umsehen im Netz gibt es folgenden Workaround:
/etc/apache2/httpd.conf.local
AcceptMutex fcntl
Danach zeigt, das error_log:
[debug] prefork.c(955): AcceptMutex: fcntl (default: pthread)
Kernel:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der Fehler trat auch beim Installationskernel, und den weiteren Updates auf.
Irgendwie habe ich den Eindruck, daß das so nicht richtig ist. Wer weiß näheres?
Da sind wohl teilweise noch alte Pakete installiert.
rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1
Schau auch mal nach folgendem: rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686
Peter
Hier das Ergebnis: # rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1 # rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686 SuSE Linux 9.2 (i686) glibc SuSE Linux 9.2 (i686) db-devel SuSE Linux 9.2 (i686) db Für mich sieht das auf den ersten Blick nach 9.2 Paketen aus. Andreas
On Fri, Dec 03, 2004 at 10:34:36AM +0100, Andreas Ernst wrote:
nachdem Update von 9.1 auf 9.2 funktioniert Apache2 nicht mehr:
[emerg] (38)Function not implemented: Couldn't create accept lock
Deinstallieren und löschen aller Konfig-Dateien brachte keine Besserung.
Nach etwas Umsehen im Netz gibt es folgenden Workaround:
/etc/apache2/httpd.conf.local
AcceptMutex fcntl
Danach zeigt, das error_log:
[debug] prefork.c(955): AcceptMutex: fcntl (default: pthread)
Kernel:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der Fehler trat auch beim Installationskernel, und den weiteren Updates auf.
Irgendwie habe ich den Eindruck, daß das so nicht richtig ist. Wer weiß näheres?
Da sind wohl teilweise noch alte Pakete installiert.
rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1
Schau auch mal nach folgendem: rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686
Peter
Hier das Ergebnis:
# rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1 # rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686 SuSE Linux 9.2 (i686) glibc SuSE Linux 9.2 (i686) db-devel SuSE Linux 9.2 (i686) db
Für mich sieht das auf den ersten Blick nach 9.2 Paketen aus.
Das sieht auch sonst okay aus. Dann kann ich Dir nicht sagen was auf Deinem System anders ist. Die Kette ist: apache benutzt libapr0 benutzt glibc benutzt kernel. An einer Stelle gibt es eine Inkompatibilitaet, die so nicht vorhanden waere, wenn Dein System "9.2 aus einem Guss" waere. Aus dem Bauch heraus wuerde ich vermuten dass die Chancen mit den glibc- und db-Paketen der i586-Kompilation (findest Du auf der CD/DVD) besser sind. Mit den i686-Builds funktionierts anderwo aber auch. Bist Du sicher dass Du den richtigen Kernel bootest? Peter
Hallo Peter, poeml@cmdline.net schrieb:
On Fri, Dec 03, 2004 at 10:34:36AM +0100, Andreas Ernst wrote:
nachdem Update von 9.1 auf 9.2 funktioniert Apache2 nicht mehr:
[emerg] (38)Function not implemented: Couldn't create accept lock
Deinstallieren und löschen aller Konfig-Dateien brachte keine Besserung.
Nach etwas Umsehen im Netz gibt es folgenden Workaround:
/etc/apache2/httpd.conf.local
AcceptMutex fcntl
Danach zeigt, das error_log:
[debug] prefork.c(955): AcceptMutex: fcntl (default: pthread)
Kernel:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der Fehler trat auch beim Installationskernel, und den weiteren Updates auf.
Irgendwie habe ich den Eindruck, daß das so nicht richtig ist. Wer weiß näheres?
Da sind wohl teilweise noch alte Pakete installiert.
rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1
Schau auch mal nach folgendem: rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686
Peter
Hier das Ergebnis:
# rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1 # rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686 SuSE Linux 9.2 (i686) glibc SuSE Linux 9.2 (i686) db-devel SuSE Linux 9.2 (i686) db
Für mich sieht das auf den ersten Blick nach 9.2 Paketen aus.
Das sieht auch sonst okay aus.
Dann kann ich Dir nicht sagen was auf Deinem System anders ist. Die Kette ist: apache benutzt libapr0 benutzt glibc benutzt kernel. An einer Stelle gibt es eine Inkompatibilitaet, die so nicht vorhanden waere, wenn Dein System "9.2 aus einem Guss" waere.
Aus dem Bauch heraus wuerde ich vermuten dass die Chancen mit den glibc- und db-Paketen der i586-Kompilation (findest Du auf der CD/DVD) besser sind. Mit den i686-Builds funktionierts anderwo aber auch. Bist Du sicher dass Du den richtigen Kernel bootest?
Peter
Ich verwende zum Booten Grub, ich habe das letzte Kernel-Update gemacht: uname -a zeigt mir folgenden Kernel an: Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux Als Dateisystem verwende ich EXT3, dachte schon das es evtl daran liegt. Andreas
On Fri, Dec 03, 2004 at 11:58:34AM +0100, Andreas Ernst wrote:
On Fri, Dec 03, 2004 at 10:34:36AM +0100, Andreas Ernst wrote:
nachdem Update von 9.1 auf 9.2 funktioniert Apache2 nicht mehr:
[emerg] (38)Function not implemented: Couldn't create accept lock
Deinstallieren und löschen aller Konfig-Dateien brachte keine Besserung.
Nach etwas Umsehen im Netz gibt es folgenden Workaround:
/etc/apache2/httpd.conf.local
AcceptMutex fcntl
Danach zeigt, das error_log:
[debug] prefork.c(955): AcceptMutex: fcntl (default: pthread)
Kernel:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der Fehler trat auch beim Installationskernel, und den weiteren Updates auf.
Irgendwie habe ich den Eindruck, daß das so nicht richtig ist. Wer weiß näheres?
Da sind wohl teilweise noch alte Pakete installiert.
rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1
Schau auch mal nach folgendem: rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686
Peter
Hier das Ergebnis:
# rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1 # rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686 SuSE Linux 9.2 (i686) glibc SuSE Linux 9.2 (i686) db-devel SuSE Linux 9.2 (i686) db
Für mich sieht das auf den ersten Blick nach 9.2 Paketen aus.
Das sieht auch sonst okay aus.
Dann kann ich Dir nicht sagen was auf Deinem System anders ist. Die Kette ist: apache benutzt libapr0 benutzt glibc benutzt kernel. An einer Stelle gibt es eine Inkompatibilitaet, die so nicht vorhanden waere, wenn Dein System "9.2 aus einem Guss" waere.
Aus dem Bauch heraus wuerde ich vermuten dass die Chancen mit den glibc- und db-Paketen der i586-Kompilation (findest Du auf der CD/DVD) besser sind. Mit den i686-Builds funktionierts anderwo aber auch. Bist Du sicher dass Du den richtigen Kernel bootest?
Peter
Ich verwende zum Booten Grub, ich habe das letzte Kernel-Update gemacht:
uname -a zeigt mir folgenden Kernel an:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der selbe Kernel laeuft hier. # uname -a Linux orkus 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux # cat /etc/SuSE-release SuSE Linux 9.2 (i586) VERSION = 9.2 # rcapache2 status Checking for httpd2: running
Als Dateisystem verwende ich EXT3, dachte schon das es evtl daran liegt.
Ich verwende auf meinen Servern ausschliesslich ext3. Tut mir leid, ich kann Dir nicht weiter helfen. Ausser: irgendwelche Reste von eigenen Apache-Builds im System zu finden? ( -> /usr/local) Ist auch eine sehr beliebte Fehlerquelle... Mach auch ldd auf httpd2-prefork und auf die Libraries, oder starte mit strace -f -eopen. Peter
poeml@cmdline.net schrieb:
On Fri, Dec 03, 2004 at 11:58:34AM +0100, Andreas Ernst wrote:
On Fri, Dec 03, 2004 at 10:34:36AM +0100, Andreas Ernst wrote:
nachdem Update von 9.1 auf 9.2 funktioniert Apache2 nicht mehr:
[emerg] (38)Function not implemented: Couldn't create accept lock
Deinstallieren und löschen aller Konfig-Dateien brachte keine Besserung.
Nach etwas Umsehen im Netz gibt es folgenden Workaround:
/etc/apache2/httpd.conf.local
AcceptMutex fcntl
Danach zeigt, das error_log:
[debug] prefork.c(955): AcceptMutex: fcntl (default: pthread)
Kernel:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der Fehler trat auch beim Installationskernel, und den weiteren Updates auf.
Irgendwie habe ich den Eindruck, daß das so nicht richtig ist. Wer weiß näheres?
Da sind wohl teilweise noch alte Pakete installiert.
rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1
Schau auch mal nach folgendem: rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686
Peter
Hier das Ergebnis:
# rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1 # rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686 SuSE Linux 9.2 (i686) glibc SuSE Linux 9.2 (i686) db-devel SuSE Linux 9.2 (i686) db
Für mich sieht das auf den ersten Blick nach 9.2 Paketen aus.
Das sieht auch sonst okay aus.
Dann kann ich Dir nicht sagen was auf Deinem System anders ist. Die Kette ist: apache benutzt libapr0 benutzt glibc benutzt kernel. An einer Stelle gibt es eine Inkompatibilitaet, die so nicht vorhanden waere, wenn Dein System "9.2 aus einem Guss" waere.
Aus dem Bauch heraus wuerde ich vermuten dass die Chancen mit den glibc- und db-Paketen der i586-Kompilation (findest Du auf der CD/DVD) besser sind. Mit den i686-Builds funktionierts anderwo aber auch. Bist Du sicher dass Du den richtigen Kernel bootest?
Peter
Ich verwende zum Booten Grub, ich habe das letzte Kernel-Update gemacht:
uname -a zeigt mir folgenden Kernel an:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der selbe Kernel laeuft hier.
# uname -a Linux orkus 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux # cat /etc/SuSE-release SuSE Linux 9.2 (i586) VERSION = 9.2 # rcapache2 status Checking for httpd2: running
Als Dateisystem verwende ich EXT3, dachte schon das es evtl daran liegt.
Ich verwende auf meinen Servern ausschliesslich ext3.
Tut mir leid, ich kann Dir nicht weiter helfen.
Ausser: irgendwelche Reste von eigenen Apache-Builds im System zu finden? ( -> /usr/local) Ist auch eine sehr beliebte Fehlerquelle...
Mach auch ldd auf httpd2-prefork und auf die Libraries, oder starte mit strace -f -eopen.
Peter
Hallo Peter, sorry für die wirklich sehr späte Antwort, doch bei meinen Server fing die Festplatte Geräuche zu machen und die "rauchte" dann auch ab. Danach mußte ich andere Dinge tun.... Somit ist der PC wieder neu aufgesetzt, doch leider mit dem gleichen Problem. :-( Ich habe einen zweiten PC aufgestzt, da läuft Apache, ldd gibt da doch Aufschluß. kelly:/home/andreas # ldd /usr/sbin/httpd2-prefork linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0x4002b000) libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4003d000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x40053000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0x40059000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4012e000) libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x4014d000) librt.so.1 => /lib/librt.so.1 (0x4016e000) libm.so.6 => /lib/libm.so.6 (0x40181000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401a5000) libnsl.so.1 => /lib/libnsl.so.1 (0x401d7000) libpthread.so.0 => /lib/libpthread.so.0 (0x401ed000) libdl.so.2 => /lib/libdl.so.2 (0x40240000) libc.so.6 => /lib/libc.so.6 (0x40244000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) linux:~ # ldd /usr/sbin/httpd2-prefork linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0x4001c000) libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4002e000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x40044000) libdb-4.2.so => /usr/lib/tls/libdb-4.2.so (0x4004a000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4011f000) libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x4013e000) librt.so.1 => /lib/tls/librt.so.1 (0x4015f000) libm.so.6 => /lib/tls/libm.so.6 (0x40168000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4018c000) libnsl.so.1 => /lib/libnsl.so.1 (0x401be000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401d4000) libdl.so.2 => /lib/libdl.so.2 (0x401e6000) libc.so.6 => /lib/tls/libc.so.6 (0x401ea000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Und somit ist schon recht schnell klar woran es liegt: libpthread.so.0 => /lib/libpthread.so.0 (0x401ed000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401d4000) An der Datei /usr/sbin/httpd2-prefork liegt es nicht, das habe ich getestet. linux:~ # rpm -qf /lib/libpthread.so.0 glibc-2.3.3-118 kelly:/home/andreas # rpm -qf /lib/tls/libpthread.so.0 glibc-2.3.3-118 Beide Dateien unterscheiden sich. Dateien /lib/libpthread.so.0 und /lib/tls/libpthread.so.0 sind verschieden. strace -f -eopen /usr/sbin/httpd2-prefork bricht ab. Was kann ich noch tun? Andreas
On Thu, Feb 10, 2005 at 11:25:34AM +0100, Andreas Ernst wrote:
poeml@cmdline.net schrieb:
On Fri, Dec 03, 2004 at 11:58:34AM +0100, Andreas Ernst wrote:
On Fri, Dec 03, 2004 at 10:34:36AM +0100, Andreas Ernst wrote:
>nachdem Update von 9.1 auf 9.2 funktioniert Apache2 nicht mehr: > >[emerg] (38)Function not implemented: Couldn't create accept lock > >Deinstallieren und löschen aller Konfig-Dateien brachte keine >Besserung. > >Nach etwas Umsehen im Netz gibt es folgenden Workaround: > >/etc/apache2/httpd.conf.local > >AcceptMutex fcntl > >Danach zeigt, das error_log: > >[debug] prefork.c(955): AcceptMutex: fcntl (default: pthread) > >Kernel: > >Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 >athlon i386 GNU/Linux > >Der Fehler trat auch beim Installationskernel, und den weiteren >Updates auf. > >Irgendwie habe ich den Eindruck, daß das so nicht richtig ist. Wer >weiß näheres? > > > > > > Da sind wohl teilweise noch alte Pakete installiert.
rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1
Schau auch mal nach folgendem: rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686
Peter
Hier das Ergebnis:
# rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep 9.1 # rpm -qa --qf %{DISTRIBUTION}\\\ %{NAME}\\\n | grep i686 SuSE Linux 9.2 (i686) glibc SuSE Linux 9.2 (i686) db-devel SuSE Linux 9.2 (i686) db
Für mich sieht das auf den ersten Blick nach 9.2 Paketen aus.
Das sieht auch sonst okay aus.
Dann kann ich Dir nicht sagen was auf Deinem System anders ist. Die Kette ist: apache benutzt libapr0 benutzt glibc benutzt kernel. An einer Stelle gibt es eine Inkompatibilitaet, die so nicht vorhanden waere, wenn Dein System "9.2 aus einem Guss" waere.
Aus dem Bauch heraus wuerde ich vermuten dass die Chancen mit den glibc- und db-Paketen der i586-Kompilation (findest Du auf der CD/DVD) besser sind. Mit den i686-Builds funktionierts anderwo aber auch. Bist Du sicher dass Du den richtigen Kernel bootest?
Peter
Ich verwende zum Booten Grub, ich habe das letzte Kernel-Update gemacht:
uname -a zeigt mir folgenden Kernel an:
Linux kelly 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux
Der selbe Kernel laeuft hier.
# uname -a Linux orkus 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 athlon i386 GNU/Linux # cat /etc/SuSE-release SuSE Linux 9.2 (i586) VERSION = 9.2 # rcapache2 status Checking for httpd2: running
Als Dateisystem verwende ich EXT3, dachte schon das es evtl daran liegt.
Ich verwende auf meinen Servern ausschliesslich ext3.
Tut mir leid, ich kann Dir nicht weiter helfen.
Ausser: irgendwelche Reste von eigenen Apache-Builds im System zu finden? ( -> /usr/local) Ist auch eine sehr beliebte Fehlerquelle...
Mach auch ldd auf httpd2-prefork und auf die Libraries, oder starte mit strace -f -eopen.
Peter
Hallo Peter,
sorry für die wirklich sehr späte Antwort, doch bei meinen Server fing die Festplatte Geräuche zu machen und die "rauchte" dann auch ab. Danach mußte ich andere Dinge tun....
Somit ist der PC wieder neu aufgesetzt, doch leider mit dem gleichen Problem. :-(
Ich habe einen zweiten PC aufgestzt, da läuft Apache, ldd gibt da doch Aufschluß.
kelly:/home/andreas # ldd /usr/sbin/httpd2-prefork linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0x4002b000) libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4003d000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x40053000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0x40059000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4012e000) libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x4014d000) librt.so.1 => /lib/librt.so.1 (0x4016e000) libm.so.6 => /lib/libm.so.6 (0x40181000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401a5000) libnsl.so.1 => /lib/libnsl.so.1 (0x401d7000) libpthread.so.0 => /lib/libpthread.so.0 (0x401ed000) libdl.so.2 => /lib/libdl.so.2 (0x40240000) libc.so.6 => /lib/libc.so.6 (0x40244000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
linux:~ # ldd /usr/sbin/httpd2-prefork linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0x4001c000) libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4002e000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x40044000) libdb-4.2.so => /usr/lib/tls/libdb-4.2.so (0x4004a000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4011f000) libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x4013e000) librt.so.1 => /lib/tls/librt.so.1 (0x4015f000) libm.so.6 => /lib/tls/libm.so.6 (0x40168000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4018c000) libnsl.so.1 => /lib/libnsl.so.1 (0x401be000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401d4000) libdl.so.2 => /lib/libdl.so.2 (0x401e6000) libc.so.6 => /lib/tls/libc.so.6 (0x401ea000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Und somit ist schon recht schnell klar woran es liegt:
libpthread.so.0 => /lib/libpthread.so.0 (0x401ed000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401d4000)
An der Datei /usr/sbin/httpd2-prefork liegt es nicht, das habe ich getestet.
linux:~ # rpm -qf /lib/libpthread.so.0 glibc-2.3.3-118
kelly:/home/andreas # rpm -qf /lib/tls/libpthread.so.0 glibc-2.3.3-118
Beide Dateien unterscheiden sich. Dateien /lib/libpthread.so.0 und /lib/tls/libpthread.so.0 sind verschieden.
strace -f -eopen /usr/sbin/httpd2-prefork bricht ab.
Was kann ich noch tun?
Andreas
Das Quote ist schon ziemlich lang, hat aber in diesem Fall sehr geholfen um mein Gedaechtnis aufzufrischen, weil's schon so lange her war. :) Also auf "kelly" tuts nicht, waehrend's auf "linux" tut? Mach mal auf beiden Rechnern rpm -qa --qf %{distribution}\\\ %{name}\\\n | grep i686 Sind auf "linux", wo's tut, keine i686-Pakete installiert? Welche Hardware ist das jeweils? cat /proc/cpuinfo auf beiden Maschinen... Die i686 glibc tut nicht auf allen Prozessoren. Mit den i586 Paketen kann im Normalfall nichts schiefgehen, die laufen ueberall, nur dass NPTL i686 Hardware voraussetzt, was in diesem Fall ist die NPTL egal. Was sagt 'getconf GNU_LIBPTHREAD_VERSION' auf beiden Maschinen? strace bricht ab mit welcher Meldung? Koennte auch ein Hinweis sein der in die aehnliche Richtug geht. Ich wuerde die i586 Pakete installieren. init 1, rpm -Uhv $CD1/suse/i586/{glibc,db,db-devel}.rpm Peter -- the little can of spam got the tasty cardinal
poeml@cmdline.net schrieb:
[...]
Hallo Peter,
sorry für die wirklich sehr späte Antwort, doch bei meinen Server fing die Festplatte Geräuche zu machen und die "rauchte" dann auch ab. Danach mußte ich andere Dinge tun....
Somit ist der PC wieder neu aufgesetzt, doch leider mit dem gleichen Problem. :-(
Ich habe einen zweiten PC aufgestzt, da läuft Apache, ldd gibt da doch Aufschluß.
kelly:/home/andreas # ldd /usr/sbin/httpd2-prefork linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0x4002b000) libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4003d000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x40053000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0x40059000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4012e000) libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x4014d000) librt.so.1 => /lib/librt.so.1 (0x4016e000) libm.so.6 => /lib/libm.so.6 (0x40181000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401a5000) libnsl.so.1 => /lib/libnsl.so.1 (0x401d7000) libpthread.so.0 => /lib/libpthread.so.0 (0x401ed000) libdl.so.2 => /lib/libdl.so.2 (0x40240000) libc.so.6 => /lib/libc.so.6 (0x40244000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
linux:~ # ldd /usr/sbin/httpd2-prefork linux-gate.so.1 => (0xffffe000) libz.so.1 => /lib/libz.so.1 (0x4001c000) libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4002e000) libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x40044000) libdb-4.2.so => /usr/lib/tls/libdb-4.2.so (0x4004a000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4011f000) libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x4013e000) librt.so.1 => /lib/tls/librt.so.1 (0x4015f000) libm.so.6 => /lib/tls/libm.so.6 (0x40168000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4018c000) libnsl.so.1 => /lib/libnsl.so.1 (0x401be000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401d4000) libdl.so.2 => /lib/libdl.so.2 (0x401e6000) libc.so.6 => /lib/tls/libc.so.6 (0x401ea000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Und somit ist schon recht schnell klar woran es liegt:
libpthread.so.0 => /lib/libpthread.so.0 (0x401ed000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401d4000)
An der Datei /usr/sbin/httpd2-prefork liegt es nicht, das habe ich getestet.
linux:~ # rpm -qf /lib/libpthread.so.0 glibc-2.3.3-118
kelly:/home/andreas # rpm -qf /lib/tls/libpthread.so.0 glibc-2.3.3-118
Beide Dateien unterscheiden sich. Dateien /lib/libpthread.so.0 und /lib/tls/libpthread.so.0 sind verschieden.
strace -f -eopen /usr/sbin/httpd2-prefork bricht ab.
Was kann ich noch tun?
Andreas
Das Quote ist schon ziemlich lang, hat aber in diesem Fall sehr geholfen um mein Gedaechtnis aufzufrischen, weil's schon so lange her war. :)
Also auf "kelly" tuts nicht, waehrend's auf "linux" tut?
Mach mal auf beiden Rechnern rpm -qa --qf %{distribution}\\\ %{name}\\\n | grep i686 Sind auf "linux", wo's tut, keine i686-Pakete installiert?
kelly:/home/andreas # rpm -qa --qf %{distribution}\\\ %{name}\\\n | grep i686 SUSE LINUX 9.2.1 (i686) glibc-devel SuSE Linux 9.2 (i686) db SUSE LINUX 9.2.1 (i686) glibc SUSE LINUX 9.2.1 (i686) glibc-debuginfo SUSE LINUX 9.2.1 (i686) glibc-i18ndata SUSE LINUX 9.2.1 (i686) glibc-profile SUSE LINUX 9.2.1 (i686) glibc-locale SUSE LINUX 9.2.1 (i686) glibc-info Die 9.2.1 Version sind hiervon: ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/projects/glibc/ Stonki schickte mit 'ne PM, und empfahl mir die neue glib zu testen, doch leider scheiterte apt beim download... linux:~ # rpm -qa --qf %{distribution}\\\ %{name}\\\n | grep i686 SuSE Linux 9.2 (i686) glibc SuSE Linux 9.2 (i686) db
Welche Hardware ist das jeweils? cat /proc/cpuinfo auf beiden Maschinen... Die i686 glibc tut nicht auf allen Prozessoren. Mit den i586 Paketen kann im Normalfall nichts schiefgehen, die laufen ueberall, nur dass NPTL i686 Hardware voraussetzt, was in diesem Fall ist die NPTL egal.
kelly:/home/andreas # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) stepping : 1 cpu MHz : 1250.200 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow bogomips : 2473.98 linux:~ # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 1800+ stepping : 2 cpu MHz : 1533.973 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow bogomips : 3039.23
Was sagt 'getconf GNU_LIBPTHREAD_VERSION' auf beiden Maschinen?
kelly:/home/andreas # getconf GNU_LIBPTHREAD_VERSION linuxthreads-0.10 intranet:~ # getconf GNU_LIBPTHREAD_VERSION NPTL 2.3.3 ?!?!?! Sollten die nicht gleich sein?!?!?
strace bricht ab mit welcher Meldung? Koennte auch ein Hinweis sein der in die aehnliche Richtug geht.
kelly:/home/andreas # strace -f -eopen /usr/sbin/httpd2-prefork open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libz.so.1", O_RDONLY) = 3 open("/usr/lib/libaprutil-0.so.0", O_RDONLY) = 3 open("/usr/lib/libgdbm.so.3", O_RDONLY) = 3 open("/usr/lib/libdb-4.2.so", O_RDONLY) = 3 open("/usr/lib/libexpat.so.0", O_RDONLY) = 3 open("/usr/lib/libapr-0.so.0", O_RDONLY) = 3 open("/lib/librt.so.1", O_RDONLY) = 3 open("/lib/libm.so.6", O_RDONLY) = 3 open("/lib/libcrypt.so.1", O_RDONLY) = 3 open("/lib/libnsl.so.1", O_RDONLY) = 3 open("/lib/libpthread.so.0", O_RDONLY) = 3 open("/lib/libdl.so.2", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/etc/apache2/httpd.conf", O_RDONLY) = 3 open("/etc/apache2/uid.conf", O_RDONLY) = 4 open("/etc/apache2/server-tuning.conf", O_RDONLY) = 4 open("/etc/apache2/sysconfig.d/loadmodule.conf", O_RDONLY) = 4 open("/usr/lib/apache2-prefork/mod_access.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_actions.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_alias.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_auth.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_auth_dbm.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_autoindex.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_cgi.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_dir.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_env.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_expires.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_include.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_log_config.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_mime.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_negotiation.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_setenvif.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_ssl.so", O_RDONLY) = 5 open("/etc/ld.so.cache", O_RDONLY) = 5 open("/usr/lib/libssl.so.0.9.7", O_RDONLY) = 5 open("/usr/lib/libcrypto.so.0.9.7", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_suexec.so", O_RDONLY) = 5 open("/usr/lib/apache2-prefork/mod_userdir.so", O_RDONLY) = 5 open("/etc/apache2/listen.conf", O_RDONLY) = 4 open("/etc/apache2/mod_log_config.conf", O_RDONLY) = 4 open("/etc/apache2/sysconfig.d/global.conf", O_RDONLY) = 4 open("/etc/apache2/mod_status.conf", O_RDONLY) = 4 open("/etc/apache2/mod_info.conf", O_RDONLY) = 4 open("/etc/apache2/mod_usertrack.conf", O_RDONLY) = 4 open("/etc/apache2/mod_autoindex-defaults.conf", O_RDONLY) = 4 open("/etc/apache2/mod_mime-defaults.conf", O_RDONLY) = 4 open("/etc/apache2/errors.conf", O_RDONLY) = 4 open("/etc/apache2/ssl-global.conf", O_RDONLY) = 4 open("/etc/apache2/default-server.conf", O_RDONLY) = 4 open("/etc/apache2/mod_userdir.conf", O_RDONLY) = 5 open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) open("/etc/apache2/conf.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5 open("/etc/apache2/conf.d/jk.conf", O_RDONLY) = 5 open("/etc/apache2/conf.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5 open("/etc/apache2/sysconfig.d/include.conf", O_RDONLY) = 4 open("/etc/apache2/vhosts.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 open("/etc/apache2/vhosts.d/extranet.ae-online.de.conf", O_RDONLY) = 4 open("/etc/apache2/vhosts.d/extranet.ae-online.de.ssl.conf", O_RDONLY) = 4 open("/var/log/apache2/error_log", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666) = 6 open("/var/log/apache2/extranet", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666) = 7 open("/var/log/apache2/access_log", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666) = 8 open("/var/log/apache2/extranet", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666) = 9 open("/etc/apache2/mime.types", O_RDONLY) = 10 open("/dev/urandom", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 10 open("/dev/zero", O_RDWR) = 10 open("/etc/localtime", O_RDONLY) = 10
Ich wuerde die i586 Pakete installieren. init 1, rpm -Uhv $CD1/suse/i586/{glibc,db,db-devel}.rpm
Peter
Würde ich dann tun, wenn Dir nix mehr einfällt..... Die Konfiguration der beiden PC's ist *ähnlich*, in kelly ist jedoch noch eine Fritz DSL Karte drin.. Andreas P.S. Danke für Deine Hilfe.
On Sat, Feb 12, 2005 at 01:26:03PM +0100, Andreas Ernst wrote:
Also auf "kelly" tuts nicht, waehrend's auf "linux" tut?
Mach mal auf beiden Rechnern rpm -qa --qf %{distribution}\\\ %{name}\\\n | grep i686 Sind auf "linux", wo's tut, keine i686-Pakete installiert?
kelly:/home/andreas # rpm -qa --qf %{distribution}\\\ %{name}\\\n | grep i686 SUSE LINUX 9.2.1 (i686) glibc-devel SuSE Linux 9.2 (i686) db SUSE LINUX 9.2.1 (i686) glibc SUSE LINUX 9.2.1 (i686) glibc-debuginfo SUSE LINUX 9.2.1 (i686) glibc-i18ndata SUSE LINUX 9.2.1 (i686) glibc-profile SUSE LINUX 9.2.1 (i686) glibc-locale SUSE LINUX 9.2.1 (i686) glibc-info
Die 9.2.1 Version sind hiervon: ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/projects/glibc/ Stonki schickte mit 'ne PM, und empfahl mir die neue glib zu testen, doch leider scheiterte apt beim download...
linux:~ # rpm -qa --qf %{distribution}\\\ %{name}\\\n | grep i686 SuSE Linux 9.2 (i686) glibc SuSE Linux 9.2 (i686) db
!? Wieso bitte verwendest Du auf kelly irgendeine experimentelle glibc? Sorry, dann kann ich Dir nicht weiter helfen. Dann ist alles Glueckssache und niemand kann dir sagen ob's tut. Peter -- the pink can of spam imitated the pink can of spam
participants (2)
-
Andreas Ernst
-
poeml@cmdline.net