Absender: Peter Siering
Datum: Fr, 02.12.2005 19:36:36
Hallo allerseits,ich komme leider nur kleckerweise vorwärts. Ich habe jetzt mit den HInweisen aus http://www.ctserver.org/ftopic507.html eine neuere Version unserers Build-Ansatzes für den Kernel des IPCop zusammengebaut. Inbesondere auf den aktuelleren UML-Patch umgestellt und den erwähnten Fix eingebaut.
Zum Testen, ob das dafür sorgt, dass die IPCop-UML dann stabil unter einem 2.6.12-ct-1-Kernel läuft, bin ich vorerst bei der letzten IPCop- Fassung (1.4.6) geblieben. Die IPCop-"Abstürze" unter Last, die mich zu der erneuten Warnung vor 2.6 als Host veranlasst haben, waren damit perfekt zu reproduzieren.
Leider kann ich nach wie vor durch längere Downloads Aussetzer provozieren: Zum bekannten Fehlerbild (IPCop-Instanz beendet sich) gesellt sich als neue Form ein Stehenbleiben des Downloads (der IPCop lebt weiter).
Ich will noch einige Dinge ausprobieren, möchte aber auch auf diesem Weg eine Suche nach möglichen Ursachen anstoßen - dazu eine genauere Beschreibung des Testszenarios und der beteiligten Systeme:
- Server ist ein C3 mit 533 MHz, Kernel 2.6.12-ct-1 - IPCop 1.4.6 mit Kernel 2.4.29 - als Testclient dient Mac OS X 10.3, Download eines ISOs mit curlDer IPCop wird über das mit der Version 1.4.6 gelieferte init-Skript gestartet, das heißt, er läuft in einer chroot-Umgebung. Das Kernel- Binary ist dazu statisch gelinkt (CONFIG_SKAS und CONFIG-TT gesetzt; nicht aber CONFIG_STATIC_LINK - das ist kaputt, CONFIG_TT hat den gleichen Effekt). Hier die vollständigen Optionen aus dem .config, das in Build-Umgebung eingebaut ist:
CONFIG_USERMODE=y CONFIG_MODE_SKAS=y CONFIG_MODE_TT=y # CONFIG_UML_SMP is not set # CONFIG_UML_WATCHDOG is not set CONFIG_UML_SOUND=n CONFIG_UML_NET=y CONFIG_UML_NET_ETHERTAP=y CONFIG_UML_NET_TUNTAP=y CONFIG_UML_NET_SLIP=y CONFIG_UML_NET_SLIRP=y CONFIG_UML_NET_DAEMON=y CONFIG_UML_NET_MCAST=y # CONFIG_UML_NET_PCAP is not set CONFIG_STATIC_LINK=n CONFIG_HOSTFS=n CONFIG_HUMFS=n CONFIG_HPPFS=n CONFIG_MCONSOLE=y CONFIG_MAGIC_SYSRQ=n CONFIG_HOST_2G_2G=n CONFIG_UML_SMP=n CONFIG_NEST_LEVEL=0 CONFIG_KERNEL_HALF_GIGS=1 CONFIG_PROC_MM=n CONFIG_KERNEL_STACK_ORDER=2 CONFIG_UML_REAL_TIME_CLOCK=y CONFIG_SSL=y CONFIG_FD_CHAN=y CONFIG_NULL_CHAN=y CONFIG_PORT_CHAN=y CONFIG_PTY_CHAN=y CONFIG_TTY_CHAN=y CONFIG_XTERM_CHAN=y CONFIG_SSL_CHAN="pty" CONFIG_CON_CHAN=xterm CONFIG_CON_ZERO_CHAN=fd:0,fd:1 CONFIG_TTY_LOG=n CONFIG_BLK_DEV_UBD=y # CONFIG_BLK_DEV_UBD_SYNC is not set CONFIG_COW=y CONFIG_MMAPPER=n CONFIG_PPP_MPPE=m CONFIG_DEBUG_SLAB=n CONFIG_DEBUGSYM=n CONFIG_O1_OPTIM=n Mich würde interessieren:- ob ich der einzige bin, der einen so lahmen Server einsetzt ;-) (Der Fehler ließ sich auch mit schnelleren Systemen reproduzieren; ich habe vorerst nur das o.g. Test-Set gequält)
- ob/wie die für die funktionierenden UML-IPCops gesetzten Kernel- Optionen (.config) abweichen
- welche Compiler beim Übersetzen des Kernels zum Einsatz kommen (bei mir ist es der für den IPCop selbst verwendete 3.3.3 in der chroot- Umgebung des IPCop)
- was für maximale uptimes mit der Kombination 2.6.12-ct-1 und UML- IPCop erreicht worden sind?
Danke+Gruß, Peter