RootForum Community

Hallo,

habe einen Strato Root Server, der jetzt unter Gentoo Linux rennt.
wenn ich zum Beispiel eine 500 MB Datei mit gzip zusammenpacke, dann kann es vorkommen, das der server komplett stehen bleibt. Keine Kernel Panic oder sowas, keine Einträge im Logfile....
Server ist komplett weg.
Starte ich das System im Recoverymode und packe die gleiche Datei, dann funktioniert es IMMER.
Kernel ist Version 2.6.4 Jemand einen Tipp wie ich dem Problem auf die Spur komme ?
Hab auch schon mal die HDParm parameter abgeschaltet, aber das brachte auch keine besserung.
Es scheint auch nur dann aufzutreten wenn cpu und festplatte zusammen viel verwendet werden.
wenn ich z.b. John verwende was reine cpu leistung nimmt, rennt der server tagelang durch.

was für ne hardware hat dein server denn?
die werte die du bei hdparm benutzt wären hier auch ganz hilfreich.

emerge info:

Portage 2.0.50-r6 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.6.4)
=================================================================
System uname: 2.6.4 i686 Intel(R) Celeron(R) CPU 2.40GHz
Gentoo Base System version 1.4.9
Autoconf: sys-devel/autoconf-2.58-r1
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=i686 -funroll-loops -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/s
hare/config /usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=i686 -funroll-loops -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://212.219.247.20/sites/www.ibiblio.org/gentoo/ http://212.2
19.247.18/sites/www.ibiblio.org/gentoo/ ftp://ftp.snt.utwente.nl/pub/os/linux/ge
ntoo http://212.219.247.11/sites/www.ibiblio.org/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X apm arts avi berkdb crypt cups encode esd foomaticdb gd-external gdbm gif
gnome gpm gtk gtk2 imap imlib java jpeg kde libg++ libwww mad maildir mikmod mo
tif mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt qu
icktime readline sasl sdl slang spell ssl svga tcltk tcpd truetype x86 xml2 xmms
xv zlib"


/etc/conf.d/hdparm
# Copyright 2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License, v2 or later
# $Header: /home/cvsroot/gentoo-x86/sys-apps/hdparm/files/hdparm-conf.d,v 1.1 2003/03/01 21:17:39 sethbc Exp $

# You can either set hdparm arguments for each drive using disc*_args and cdrom*_args..
# eg.
# disc0_args="-d1 -X66"
# disc1_args"-d1"
# cdrom0_args="-d1"

# Or, you can set hdparm options for ALL drives using all_args..
# eg.
# this mimics the behavior of the current script
all_args="-d1 -X66"

dmesg:

Linux version 2.6.4 (root@mail) (gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)) #2 Thu May 6 11:35:22 CEST 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 131056
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 126960 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 IntelR ) @ 0x000f6940
ACPI: RSDT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000
ACPI: FADT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
ACPI: DSDT (v001 INTELR AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
Built 1 zonelists
Kernel command line: root=/dev/hda4 console=tty0 console=ttyS0,57600
No local APIC present or hardware disabled
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 2400.038 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Memory: 514364k/524224k available (2586k kernel code, 9104k reserved, 783k data, 356k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4734.97 BogoMIPS
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000
CPU: After vendor identify, caps: bfebf9ff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 128K
CPU: After all inits, caps: bfebf9ff 00000000 00000000 00000080
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU#0: Thermal monitoring enabled
CPU: Intel(R) Celeron(R) CPU 2.40GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb360, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/2440] at 0000:00:1f.0
PCI: IRQ 0 for device 0000:02:08.0 doesn't match PIRQ mask - try pci=usepirqmask
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.13 <tigran@veritas.com>
VFS: Disk quotas dquot_6.5.1
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
udf: registering filesystem
Initializing Cryptographic API
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel i845 Chipset.
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 4M @ 0xe3000000
[drm] Initialized i830 1.3.2 20021108 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
parport0: PC-style at 0x378 (0x778) [PCSPP(,...)]
parport0: irq 7 detected
Using anticipatory io scheduler
FDC 0 is a post-1991 82077
Intel(R) PRO/1000 Network Driver - version 5.2.30.1-k2
Copyright (c) 1999-2004 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.0.16
e100: Copyright(c) 1999-2004 Intel Corporation
PCI: Assigned IRQ 12 for device 0000:02:06.0
e100: eth0: e100_probe: addr 0xe2200000, irq 12, MAC addr 00:30:48:52:D9:C4
PCI: Assigned IRQ 12 for device 0000:02:07.0
PCI: Sharing IRQ 12 with 0000:02:08.0
e100: eth1: e100_probe: addr 0xe2201000, irq 12, MAC addr 00:30:48:52:D9:C5
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH2: IDE controller at PCI slot 0000:00:1f.1
ICH2: chipset revision 5
ICH2: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: ExcelStor Technology J360, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: 120103200 sectors (61492 MB) w/1821KiB Cache, CHS=16383/255/63, UDMA(100)
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4
libata version 1.01 loaded.
USB Universal Host Controller Interface driver v2.2
drivers/usb/core/usb.c: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
drivers/usb/core/usb.c: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Advanced Linux Sound Architecture Driver Version 1.0.2c (Thu Feb 05 15:41:49 2004 UTC).
ALSA device list:
No soundcards found.
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
ip_conntrack version 2.1 (4095 buckets, 32760 max) - 296 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. http://snowman.net/projects/ipt_recent/
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
NET: Registered protocol family 17
found reiserfs format "3.6" with standard journal
Reiserfs journal params: device hda4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
reiserfs: checking transaction log (hda4) for (hda4)
Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 356k freed
Adding 514072k swap on /dev/hda2. Priority:-1 extents:1
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
process `named' is using obsolete setsockopt SO_BSDCOMPAT
hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }

hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest }

Führe bitte folgendermassen ein Systemupdate durch:

1.) /etc/make.conf optimieren
2.) Sstem im Hintergrund updaten (dauert mehrere Stunden):
3.) Ausloggen und ~6 Stunden warten:
4.) Reboot durchführen.
5.) Kernel updaten.

MAKEOPTS="-j1"

Ganz doofe Frage: wieso 1? Welchen Vorteil sollte das für die Stabilität bringen? Dauert doch einfach nur länger beim kompilieren...

Normalerweise sollte das 1 + Anzahl CPUs sein oder?

Ansonsten würde ich Walsleben nicht umbedingt diese use flags aufzwingen. z.B. fbcon ist sinnlos. hardened ohne das entsprechende Profil bringt auch nichts.

Ich würde auch noch FEATURES="ccache" hinzufügen. Wenn möglich auch distcc

ein deratiger emerge ist auch nicht ohne. ich würde eher emerge -uUD world und revdep-rebuild ausführen.

CaptainCrunch wrote:

MAKEOPTS="-j1"

Ganz doofe Frage: wieso 1? Welchen Vorteil sollte das für die Stabilität bringen? Dauert doch einfach nur länger beim kompilieren...

Es gibt Pakete, bei denen es im ebuild expliziet auf 1 gesetzt wird. Zudem hatte ich leider auch kleinere unreproduzierbare Instabilitäten, welche mit 1 und einem vollständigem Rebuild nicht auftraten.

øxygen wrote:Ansonsten würde ich Walsleben nicht umbedingt diese use flags aufzwingen. z.B. fbcon ist sinnlos.

Hint: black console with kernel 2.6.x

øxygen wrote:hardened ohne das entsprechende Profil bringt auch nichts.

Du solltest Dir die relevanten ebuilds/configs/patches/etc. hin und wieder direkt ansehen, es steht nicht immer Alles im Changelog ;) Es gab in den letzten Wochen jede Menge Ã?nderungen der USE-Flags und Abhängigkeiten (+/-).

øxygen wrote:Ich würde auch noch FEATURES="ccache" hinzufügen. Wenn möglich auch distcc

Beim normalen Kompilieren ja, aber bei einem Upgrade von 1.4.9 auf 1.4.15 nicht. Es hat sich nunmal zu viel geändert.

øxygen wrote:ein deratiger emerge ist auch nicht ohne.

ACK.

øxygen wrote:ich würde eher emerge -uUD world und revdep-rebuild ausführen.

Siehe oben, es reicht nicht wirklich...

Ich werde den Vorschlag von 'Joe User' testen.
Emerge rennt grade. werde morgen früh mal berichten was es gebracht hat.

das complete rebuild der pakete klappt so leider nicht. damit bleibt er bei dem gcc hängen.

dann hab ich es mal mit emerge R sys-apps/groff probiert und dann wieder das script /usr/portage/sys-devel/gcc/files/scan_libgcc_linked_ssp.sh zum testen ob das problem jetzt weg ist. Leider bleibt er dann bei dem schritt 2 hängen und meckert die R.lib (oder war es R.bin) an.

ich hab jetzt die CFLAGS '-fstack-protector -fstack-protector-all' rausgenommen und mache nochmal ein full rebuild.
[/code]

STOP! Nimm dann bitte auch das hardened USE-Flag raus.

Hab ich grade gemerkt.
er bleibt dann wieder beim gcc hängen.

und auf ein neues in 90 minuten weiß ich mehr. ;)

Joe User wrote:

CaptainCrunch wrote:

MAKEOPTS="-j1"

Ganz doofe Frage: wieso 1? Welchen Vorteil sollte das für die Stabilität bringen? Dauert doch einfach nur länger beim kompilieren...

Es gibt Pakete, bei denen es im ebuild expliziet auf 1 gesetzt wird. Zudem hatte ich leider auch kleinere unreproduzierbare Instabilitäten, welche mit 1 und einem vollständigem Rebuild nicht auftraten.

Ja das stimmt der X-Server und OpenOffice sind solche Kandidaten. Dann würde ich die Option aber einfach weglassen.

øxygen wrote:Ansonsten würde ich Walsleben nicht umbedingt diese use flags aufzwingen. z.B. fbcon ist sinnlos.

Hint: black console with kernel 2.6.x

Stört das auf nem Rootserver? Also mir wäre es egal ;)

øxygen wrote:hardened ohne das entsprechende Profil bringt auch nichts.

Du solltest Dir die relevanten ebuilds/configs/patches/etc. hin und wieder direkt ansehen, es steht nicht immer Alles im Changelog ;) Es gab in den letzten Wochen jede Menge Ã?nderungen der USE-Flags und Abhängigkeiten (+/-).

Siehe folgender Post von Walsleben ;)

øxygen wrote:Ich würde auch noch FEATURES="ccache" hinzufügen. Wenn möglich auch distcc

Beim normalen Kompilieren ja, aber bei einem Upgrade von 1.4.9 auf 1.4.15 nicht. Es hat sich nunmal zu viel geändert.

hm, also das musst du erklären, in wiefern soll das einen Unterschied machen, vorallem beziehst du dich auf ccache oder distcc?

Ja das stimmt der X-Server und OpenOffice sind solche Kandidaten.

Ich dachte bis gerade eben, dass es hier um Rootserver ginge?!? ;)

SCNR

øxygen wrote:Ja das stimmt der X-Server und OpenOffice sind solche Kandidaten. Dann würde ich die Option aber einfach weglassen.

Ich schreibe hier über Server und nicht über Desktops.
BTW: Lies Dir mal die entsprechenden Abschnitte in den Docs zur glibc und zum gcc durch. Auch dort wird nicht grundlos von > -j1 abgeraten...

øxygen wrote:

Joe User wrote:

øxygen wrote:Ansonsten würde ich Walsleben nicht umbedingt diese use flags aufzwingen. z.B. fbcon ist sinnlos.

Hint: black console with kernel 2.6.x

Stört das auf nem Rootserver? Also mir wäre es egal ;)

Serielle Console.

øxygen wrote:hm, also das musst du erklären, in wiefern soll das einen Unterschied machen, vorallem beziehst du dich auf ccache oder distcc?

1.) distcc http://distcc.samba.org/ der erste Satz reicht völlig.
2.) ccache http://ccache.samba.org/ der zweite Satz reicht ebenfalls, oder mixed Du gerne inkompatiblen Code, nur weil zufällig ein unbedeutender Hashwert über mehrere Produktversionen hinweg gleich bleibt?

Joe User wrote: Serielle Console.

Die funktioniert auch mit kaputten/keinem Framebuffer. ;)

øxygen wrote:hm, also das musst du erklären, in wiefern soll das einen Unterschied machen, vorallem beziehst du dich auf ccache oder distcc?

1.) distcc http://distcc.samba.org/ der erste Satz reicht völlig.

distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network. distcc should always generate the same results as a local build, is simple to install and use, and is often two or more times faster than a local compile.
Ich sehe da keinen Hinweis auf Probleme. Ich hab selbst schon mehrere Maschinen mit distcc bootstrapped, ohne Probleme.

2.) ccache http://ccache.samba.org/ der zweite Satz reicht ebenfalls, oder mixed Du gerne inkompatiblen Code nur weil ein Hashwert über mehrere Versionen hinweg gleich bleibt?

Ã?ber die Chance, das ein md4 hash bei zwei verschiedenen Dateien gleich bliebt muss ich dich nicht aufklären, oder? Auch mit ccache hatte ich noch nie Probleme.

øxygen wrote:

Joe User wrote:Serielle Console.

Die funktioniert auch mit kaputten/keinem Framebuffer. ;)

OK, ich überzeuge mich morgen selbst davon.

øxygen wrote:distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network. distcc should always generate the same results as a local build, is simple to install and use, and is often two or more times faster than a local compile.
Ich sehe da keinen Hinweis auf Probleme. Ich hab selbst schon mehrere Maschinen mit distcc bootstrapped, ohne Probleme.

;)

øxygen wrote:Ã?ber die Chance, das ein md4 hash bei zwei verschiedenen Dateien gleich bliebt muss ich dich nicht aufklären, oder?

Nein. Aber in Zeiten statische gelinkter Libs und Binarys, tritt das Problem häufig genug auf. Zwei Nullen bleiben zwei Nullen und der Hash bleibt gleich...

øxygen wrote:Auch mit ccache hatte ich noch nie Probleme.

Glückwunsch.

Joe User wrote:

øxygen wrote:distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network. distcc should always generate the same results as a local build, is simple to install and use, and is often two or more times faster than a local compile.
Ich sehe da keinen Hinweis auf Probleme. Ich hab selbst schon mehrere Maschinen mit distcc bootstrapped, ohne Probleme.

;)

Das man distcc nur benutzt wenn man mehrere Maschinen zur Verfügung hat, hielt ich für selbst verfreilich. Deswegen auch die Einschränkung in meinem Urspungspost. Klar, wenn man nur einen Rechner zum kompilieren hat, macht das wenig Sinn, aber Probleme macht es auch nicht. distcc deaktiviert sich automatisch wenn es keine anderen Nodes findet.

Jupp und fbcon ohne Kernelunterstützung schadet ebenso wenig ;)

Alle Pakete sind neu kompiliert und hab auch jetzt einen neugebauten kernel (2.6.6) drauf.
Verbesserung hat es leider keine gebracht.
Ich bekomme es immer noch hin, das er abstürzt.
Für mich bleibt eigentlich nur noch übrig, zu 'beweisen' das es ein Hardware defekt ist.
An einen Softwarefehler glaube ich jetzt nicht mehr.
Ich hab mir parallel noch einen Routerserver bestellt und werden dann mit allen daten dahin umziehen und dann werden ich den server mal reinitalisieren lassen und testen ob ich ihn dann auch zum absturz bringen kann.

Danke für eure Hilfe

Dann wird es wahrscheinlich ein Fehler im Ram oder Mainboard sein. Also am besten mal memtest laufen lassen.

Da bin ich mal wieder,

in der zwischenzeit habe ich alle daten vom server runtergenommen und von Strato, einen Hardware check durchführen lassen.
Sie haben nix gefunden. Dann hab ich den Server auf das Strato Suse zurücksetzten lassen.
Ich hab den Server lange nicht benutzt, jetzt wollte ich ihn mal wieder einsetzten.
Und da ist wieder mein altes Problem, der Server stürzt unter manchen last umständen einfach ab.
Ich kann nicht mal sagen, woran es dann exact liegt.
Zum test der Netzwerk komponente haben ich zwischen 2 Root-Server ca. 20 GB Traffic gemacht und er lief stabil.
Als nächstes hab ich mal wie wild auf der platte geschrieben und gelesen um rauszufinden, ob der hd controller vielleicht eine Macke hat.
Das lief auch wieder sauber durch.
Damit bin ich davon ausgegangen das der Server funktioniert.

Ich wollte nun eine großere Datei mit Rsync von einem Server zu einem anderen kopieren und was ist...
Das Mist Ding ist wieder sang und klanglos abgestürzt.

Mein Problem ist, das ich es nicht hinbekomme, das die von Strato den Fehler reproduzieren können und einsehen, das die Hardware ein Problem hat.

Fällt jemand ein Toller Streßtest ein ???
Memtest rennt übrigens auch sauber durch....

Ist einfach zum heulen...

Danke

Axel

Welches Suse hast Du installieren lassen, 9.1 für Profis?

Steht irgendwas verdächtiges in den Logs?

Was sagen die smartmontools zum Zustand der Platte?

Benutzt Du hdparm? Falls ja mit welchen Parametern?

Hast Du den Kernel auf die Hardware hin optimiert sprich alles unnötige entfernt?

Falls es die Hardware hergibt könntest Du z.B. über bootparameter verschiedene Varianten probieren, die manchmal helfen:
local apic einschalten: "apic=debug lapic"
andere timerquelle wählen: "clock=pmtmr" oder "clock=tsc" oder "clock=pit"

Zum Reproduzieren des Fehlers habe ich auch keinen Tipp. Einen Compilelauf des Kernels mit j5 hast Du wohl schon probiert, oder?

tally

Hallo,

ich dachte, dass ich zu doof bin, Hardwarefehler zu identifizieren, weil ich ähnliches, wenn nicht sogar gleiches erlebt habe.

Mein Server stürzt ab, wenn ich große Dateien kopiere oder bearbeite. D.h. ich [un]zippe oder greppe Dateien >100MB (z.B. access.log). Absturz heißt, dass ab dem Zeitpunkt keine Aufzeichnungen mehr in Log-Dateien geschrieben werden; es gibt auch kein Hinweis in syslog, message oder sonstwo, was schief läuft. In der Seriellen Konsole tut sich auch nichts mehr. Der Server ist nicht mehr anpingbar, also im wahrsten Sinne des Wortes abgestüzt.
Das passiert sowohl bei eine Debian Installation al la debianhowto.de mit den Erweiterung zur Strato-Installation, die hier im Forum gepostet wurden, als auch mit einer Strato Debian-Installation, die mit debianhowto gehärtet wurde. Als Woodie Benutzer ist mein Kernel "uralt", nämlich 2.4.25.

Walsleben wrote:... und von Strato, einen Hardware check durchführen lassen.
Sie haben nix gefunden. Dann hab ich den Server auf das Strato Suse zurücksetzten lassen.

Das habe ich auch schon machen lassen und es führte zu keinem Ergebnis.
Anscheinend kann man den Hardware Check unter Absingen der Nationalhymne in der Tonne versenken. Sorry, aber die dort vorgebrachten Lösungsansätze sind für mich nicht akzeptabel. Auf der anderen Seite muss ich mich etwas zügeln, da man zum Schnäppchenpreis von 39 EUR wahrscheinlich wirklich nicht mehr bieten kann.

Trotzdem geht es mir auf den Geist, immer den Server im Auge zu behalten. Dank einer Ã?berwachung eines PCs schicke ich mir bei Serverausfall eine SMS zu (wg. E-Plus Email-Service sogar kostenlos).

Walsleben wrote:Ich wollte nun eine großere Datei mit Rsync von einem Server zu einem anderen kopieren und was ist...
Das Mist Ding ist wieder sang und klanglos abgestürzt.
Mein Problem ist, das ich es nicht hinbekomme, das die von Strato den Fehler reproduzieren können und einsehen, das die Hardware ein Problem hat.

Dito. Ein Stresstest ist bei mir das Durchsuchen, neu schreiben und Zeilen zählen von access.log-Dateien. Wenn ich mehrere Wochen durchsuche, komme ich in den GB-Bereich und der Server stürzt mit an Sicherheit grenzender Wahrscheinlichkeit ab. Selbst gefrickelt, aber ganz nett für Pageviews geeignet (Achtung: der folgende Code ist nicht für schwache Nerven geeignet). Ich würde gerne den Vertrag beenden oder eine laufende Maschine bekommen. Falls du irgendwelchen Erfolg hast, sage bitte kurz Bescheid.

Gruß
Marc