[Eisfair] Eis1 stirbt

[Ulrich Hupe]

Hallo Derya,

danke für die Anregungen s.u.
Ich denke es ist die HW / Eis1 32bit.
  die ist 16 Jahre alt (MEDIONPC MS-7204/MS-7204, BIOS 6.00 PG 10/07/2005)
RAM habe ich schon mal getauscht.
Platzprobleme habe ich nicht.
Über den fli4l kann man schon grob sehen ob es aktive Verbindungen gibt, 
die da nicht hingehören, sah ich aber nicht.

Die Prozesse sterben und die childs werden zu orphans
Beim vorletzten crash blieb die Zeit auf genau 4:00 stehen
als ich ntp via Konsole aufrief, lief nichts mehr.

Ich werde parallel einen neuen vielleicht E64 aufsetzen, das ist dann 
leider eine Neuinst. Der Rest kommt dann in die Tonne.

Auf jeden Fall werden ich schauen ob die Platte woanders booten kann.
Auch mit dem möglichen Einbruch halte ich für wichtig, untersuchenswert.

Nur, so ein Verhalten habe ich bislang noch nicht gesehen.
Sonst starben die Dinger immer sofort.

Gruß, Ulrich


>      Speicher? Irgendeinen Speichertest laufen lassen
>          Speicher rausnehmen?
>          Vertauschen?
>      HD? -> fsck mit -f(orce).
> 
> Wenn Du eine HW Problematik (except HD)  ausschliessen willst, haenge 
> doch bitte mal die HD an einen anderen Rechner. Denn der neue Kernel 
> sollte auch auf anderer HW sofort starten.
> Damit kannst Du zuegig feststellen, ob die INstalltion oder doch die HW 
> defekt war.
> 
> Wenn aber das System immer noch auf der andern HW stehen bleibt *und* 
> fsck nix erbracht hat, dann wird es haarig.
> 
> Akademisch ist es interessant raus zufinden, doch das wird Dich sicher 
> seeeehr stark binden.
> 
> Dann lieber, die /etc/config sichern, plattmachen neue installieren 
> (wenn Du kein 100/100 Backup hast, also nicht nur die Daten sondern 1:1 
> Image), die Pakete der gesicherten auf die frische Installation ziehen, 
> die config einspielen und nochmal per setup aus diesen akt. gesicherten 
> configs fuer die bin eine lauffaehige Umgebung generieren.
> 
> Was mir noch einfaellt:
> 
> Platzproblem? Wenn kein logs mehr geschrieben werden, die Process sterben?
>      Wenn ja warum.
> Keine Logs, fremde/unerlaubte Uebernahme? Und die Logs abgestellt?
> 
> Schau insbesondere in /tmp und in /var/tmp
> Ebenso koenntest Du die Maschine hinter einem Zwangsrouter stellen um 
> zusehen, ob/was sie versucht aufzubauen, welcher Traffic entsteht. Aber 
> grosser Aufwand.
> 
> Vorher vllt. einen anderen Kernel booten?
> smartctl ueber die Platten laufen lassen?
> 
> Wenn das eine historisch gewachsene Maschine ist, dann wird es 
> langwierig, denke ich. Wenn es eine neue, frische Installation ist, dann 
> peng, neu installieren, in 2-3h Stunden hast Du schon eine definitiv 
> funktionale EInheit. Denn Du hast ja die eingaben, die config-Dateien 
> schon angelegt.
> Doch unbedingt vorher die HD irgendwo anders anklemmen und schauen, ob 
> das die selbe Problematik auftaucht.
> 
> OK?
> 
> __Viel Erfolg__
> Derya
> 
> PS: Eine Idee, sofern ein Einbruch, dass Du Dir aide/tripwire 
> kompilierst und auf eis laufen laesst, so weisst Du zumindest ob nicht 
> die bins auf der Einheit gepatched = modifiziert = korrumpiert sind. 
> lsof ist immer ein Ziel, weil man mit lsof alles anzeigen kann, 
> was/wo/etc laeuft, wohin die Verbindungen gehen. Ich habe kein 
> eis1-32bit (hast Du?), sonst wuerde ich Dir die hashsumme lsof/netstats 
> schicken.
> 
> Hier sind die Hashummen lsof/netstats x64:
> 
> a64db36f0811da7ebe973a028ede330a  /usr/bin/lsof - md5sum
> ad25ffe45d2f4428786ae3b48e0e0dc175d93db0  /usr/bin/lsof - sha1sum
> 
> 2201be6b6502b8c9f41af9915e45d469  /bin/netstat - md5sum
> bc77aca05f36c7335347b0fd7fa62d41f9281248  /bin/netstat -sha1sum
> Kernel 4.9.261-eisfair-64-VIRT