SSH/Telnet Segfaults

K

kastor

Member
Hi,

ich hab ein kleines, bzw. großes Problem mit einem FreeBSD Server. Seit kurzem kann ich einige Programme, die zur Basisdistribution gehören, nicht mehr nutzen.

SSH, telnet, scp und Konsorten stürzen früher oder später mit einem segfault ab, hier ein kurzes Beispiel davon:

Code: 
(gdb) run
telnet> open mail.gmx.de 25
Trying 213.165.64.20...

Program received signal SIGSEGV, Segmentation fault.
0x0000000800aa39a0 in EVP_MD_CTX_md () from /lib/libcrypto.so.6

Ich hab schon versucht mit make buildworld & make installworld mal das Basissystem neu zu bauen, leider ohne Erfolg.

Kennt jemand eventuell das Problem und hätte eine Lösung dafür parat?

Danke schon mal im Vorraus!

Infos zum Server:
- Sun Fire X4140 (Quadcore Opteron, 8GB Ram)
- FreeBSD 8.2 release
 
Hast du noch mehr Coredumps? Gibt es Zusammenhänge z.B. alle SEGVs in der selben Lib? Sind die Fehler (halbwegs) gleichmäßig über allen Code verteilt so würde ich Hardwareschäden vermuten.
 
Hi,

Hmm, Hardwaredefekt könnte natürlich sein - nur läuft das System sonst absolut stabil und macht seinen Job (Samba Server, Postgres DB, OpenLDAP Slave, SSH Terminal). Coredumps finde ich nur von ssh, telnet und scp. Grade noch überprüft, die Fehler scheinen alle von der /lib/libcrypto.so.6 zu stammen...

Habe grade versucht den OpenSSH Server aus den Ports zu verwenden - der läuft ohne Probleme (das dazugehörige scp zum Beispiel auch).

Der einzige Unterschied zwischen den Binaries scheint zu sein, dass eine andere libcrypto gelinkt wurde:
Code: 
# ldd /usr/local/bin/scp
/usr/local/bin/scp:
        libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x800651000)
        libutil.so.8 => /lib/libutil.so.8 (0x8008e5000)
        libz.so.5 => /lib/libz.so.5 (0x8009f5000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x800b0a000)
        libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x800c23000)
        libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x800d3d000)
        libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x800eac000)
        libasn1.so.10 => /usr/lib/libasn1.so.10 (0x800fae000)
        libroken.so.10 => /usr/lib/libroken.so.10 (0x801130000)
        libc.so.7 => /lib/libc.so.7 (0x801241000)
        libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801480000)
        libhx509.so.10 => /usr/lib/libhx509.so.10 (0x80158a0

# ldd /usr/bin/scp
/usr/bin/scp:
        libcrypto.so.6 => /lib/libcrypto.so.6 (0x8008ae000)
	libz.so.5 => /lib/libz.so.5 (0x800b4f000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x800795000)       
        libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800ea3000)
        libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x800fad000)
        libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8013de000)
        libasn1.so.10 => /usr/lib/libasn1.so.10 (0x80125c000)
        libroken.so.10 => /usr/lib/libroken.so.10 (0x8015ed000)
        libc.so.7 => /lib/libc.so.7 (0x800c64000)
        libhx509.so.10 => /usr/lib/libhx509.so.10 (0x80111c000)
        libmd.so.5 => /lib/libmd.so.5 (0x8014e0000)
	libssh.so.5 => /usr/lib/libssh.so.5 (0x80064b000)

Ich glaub mir bleibt trotzdem nichts anderes übrig als mal einen Memtest zu machen, bzw. die Hardware unter Dampf zu setzen und drauf zu hoffen, dass sich etwas komisch verhält.
 
Wenn er imme nur über der einen lib abstürzt, könntest Du eine neue aus einer frischen Distribution nehmen und einen diff drüber jagen.
Sonst solltest Du auch mal einen Blick auf deine Festplatte werfen. Ggf. ist sie an der Stelle einfach defekt.
 
Es kann auch sein das eine Lib beschädigt wurde. libcrypto ist OpenSSL. Wenn dir nach Abenteuern ist kann du dir mal libmap.conf ansehen und die OpenSSL Version aus den Ports gegen den SSHd aus World linken.
 
@Crest: danke für den Tipp - zumindest das im Eingangspost aufgeführte Problem kann ich mit folgendem Eintrag in die /etc/libmap.conf "beheben" (die libcrypto.so.7 kommt aus den Ports):

Code: 
[/usr/bin/telnet]
libcrypto.so.6 libcrypto.so.7

Bezüglich der Hardware: der Server hat gestern nen Memtest über 4 Stunden ohne Fehler überstanden, fscks auf den Systemplatten (gmirror raid 1) hat auch keine Fehler ergeben.

Ich bin grade etwas ratlos, ich will solche Sachen eigentlich nicht in einem Produktivsystem stehen lassen -- gibts eventuell was, mit dem man das Problem wieder sauber in den Griff bekommt?


Danke & Gruß,

Kastor
 
Du kannst dir libcrypto neu bauen oder von einem anderen System besorgen. Interessant wäre auch die Prüfsummen voher zu vergleichen.
 
Hast du mal mehrere memtest Instanzen gleichzeitig laufen lassen? Bei mir traten an einem System (Überhitzung) erst bei 3 gleichzeitig laufenden memtests Probleme auf.
 
@Crest: werd ich mal probieren

@Kamikaze: Hitzeprobleme kann ich ausschließen, der Server läuft in einem klimatisierten Raum bei maximal 30°C unter Volllast. Die Lüfter sind soweit auch alle in Ordnung.
 
Äh.. ja, die sind bei mir trotzdem überhitzt. Wohl gemerkt bei Betrieb nach Spezifikation.

Zwischen den Riegeln staut sich die Luft, wenn du nicht senkrecht von oben draufbläst. Der Durchzug im Gehäuse bringt da so gut wie gar nichts.
 
Hast Du irgendwelche Optimierungen eingestellt beim Bauen von World? Letztens Hardware ausgetauscht?
 
Hi,

grade versucht die libcrypto.so.6 von einem anderen System zu verwenden - funktioniert leider nicht (kommt immernoch zu segfaults).

@nakal: die Fehler traten schon auf, bevor ich world gebaut habe. Momentan steht folgendes in meiner make.conf:

Code: 
# compiler flags
CFLAGS= -O2 -fno-strict-aliasing -pipe
CPUTYPE=opteron

# disable x11
WITHOUT_X11=yes

# set preferred java port
JAVA_PREFERRED_PORTS?= JAVA_PORT_NATIVE_BSDJAVA_JDK_1_6

# use sasl openldap client with openssl
.if ${.CURDIR:M*/usr/ports/net/openldap24-client*}
WITH_SASL=YES
WANT_OPENLDAP_SASL=YES
.endif

# added by use.perl 2009-02-06 15:09:40
PERL_VERSION=5.10.1

Ich werde heute abend nochmal ein make buildworld/installworld versuchen.
 
Hoi,

lass doch mal zu Testwecken die CFLAGS und den CPUTYPE in der /etc/make.conf ganz weg. Tritt das Problem dann auch auf ?

Gruß Bummibär
 
kastor schrieb:
Ich werde heute abend nochmal ein make buildworld/installworld versuchen.
Zum Vergrößern anklicken....

Vergiss nicht, einen echten GENERIC Kernel zu nehmen. Man kann gar nicht vorhersagen, was alles passiert, wenn Du -O2 überall erzwingst, wo es nicht erlaubt ist und auch da erzwingst, wo es durchaus noch mehr geht.

Das ist hier kein Gentoo... optimieren tun wir so nicht bei FreeBSD. Du kriegst auch keinen offiziellen Support, wenn Du nicht GENERIC nimmst.
 
Die CFLAGS sind schon in Ordnung, das ist auch so gedacht. Nur ist es sinnlos, weil es sowieso die Standard-CFLAGS sind.

Was er auf keinen Fall darf ist CPUTYPE so zu setzen. CPUTYPE darf nur mit ?= gesetzt werden!
 
Hi,

die CFLAGS stammen noch aus der Zeit, in der ich mit FreeBSD angefangen habe (2002?) die haben bisher keine keine Probleme verursacht, von denen ich wusste.

Ich werd trotzdem mal World & Kernel ohne jegliche zusätzliche Flags bauen.

Zum Kernel: ich verwende *nur* Generic Kernels - außer ich hab wirklich gute Gründe, eine eigene Config zu verwenden. Bisher kam das aber noch nie vor ;)

Danke Euch allen schonmal für die hilfreichen Beiträge!
 
So,

gestern abend nochmal das komplette Basisystem gebaut (streng nach Handbuch), inklusive Kernel mit generic Config und ohne irgendwelche Compilerflags in der make.conf. Leider hat das mein Problem auch nicht behoben.
Habe aber eine interessante Entdeckung dabei gemacht: nach dem make installworld im single user mode funktioniert die Bibliothek noch wie sie soll - nach dem reboot leider nicht mehr. Der MD5 Hash des Binaries ist aber derselbe.

Ich werde nicht wirklich schlau aus der Geschichte...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben