Meldung "+++ killed by SIGKILL +++"

[Leverator]

Hallo Profies,

ich habe hier ein Programm, das sich auf zwei Debian Wheezy-Maschinen unterschiedlich verhält.
Auf der einen Maschine (A) erhalte ich direkt nach dem Aufruf die Meldung "Getötet" und auf der anderen (B) wird sie anstandslos gestartet.
Der einzige Unterschied dieser Maschinen ist, daß die Maschine A vor etwa einem halben Jahr installiert worden ist und seit dem mit apt-get update / apt-get dist-upgrade auf dem aktuellsten Stand gehalten wird und die Maschine B erst innerhalb des letzten Monats.

Zurück zu dem Stück Software:
Ein ldd auf Aaschine A ergibt:
" not a dynamic executable"

Auf Maschine B:
linux-vdso.so.1 => (0x00007fff425ff000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f06fc42f000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f06fc128000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f06fbf0b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f06fbb84000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f06fb96e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f06fb769000)
/lib64/ld-linux-x86-64.so.2 (0x00007f06fc6c9000)

Die md5-Summen von ldd und der untersuchten Binary sind jeweils identisch.
Danach habe ich die md5-Summen der angegebenen Bibliotheken verglichen: Auch identisch.
Selbst die Summen der jeweils gebooteten Kernel sind identisch.

Warum verhält sich dieses Stück Software auf zwei Debian Wheezy-Systemen unterschiedlich?
Bei dem Programm handelt es sich um g3dmesh, welches um ein paar Berechnungen erweitert worden ist. Es ist auf einem SuSE 11.1-System vorkompiliert und nur das Binary auf die Debian-Maschinen kopiert worden.

Viele Grüße,
Lev

[DeletedUserReAsG]

Magst das Binary mal hochladen?

cu,
niemand

[Leverator]

@Meillo:
Wenn man ein strace des Programms auf dem Rechner, auf dem es nicht funktioniert, ausführt, dann erscheint folgende Meldung:
strace ./g3dhexa_F95_R8_Linux_DLR_intel.x
execve("./g3dhexa_F95_R8_Linux_DLR_intel.x", ["./g3dhexa_F95_R8_Linux_DLR_intel"...], [/* 17 vars */] <unfinished ...>
+++ killed by SIGKILL +++
Getötet
Und genau diese Meldung "+++ killed by SIGKILL +++" war mein Topic. Also ich wollte mit den Pluszeichen keine erhöhte Aufmerksamkeit erzeugen.

@niemand:
Leider darf ich das Binary nicht online stellen. Wegen Lizenzgedöns wurde mir das von meinem Vorgesetzten untersagt.
Aber vielleicht kannst Du mir sagen, welche Schritte ich zum Untersuchen ausführen soll...?
- obwohl: Bestimmt kann ich die Aussage aus Chefe herausquetschen, "Niemand darf das Binary bekommen." ....


Viele Grüße,
Lev

[Leverator]

Achja, noch vergessen zu erwähnen:
Starte ich das Biest mit gdb, erhalte ich folgende Meldung:
"During startup program terminated with signal SIGKILL, Killed."

Hilft das irgendwie weiter?

Grüße,
Lev

[cosmac]

hi,

Auf Maschine B:
linux-vdso.so.1 => (0x00007fff425ff000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f06fc42f000)
(...)

Ein ldd auf Aaschine A ergibt:
" not a dynamic executable"

Diese Meldung gibt's (auch), wenn man ldd in einer 32-Bit Umgebung auf ein 64-Bit Programm ansetzt (eben ausprobiert) und wahrscheinlich auch umgekehrt. file $binary sagt trotzdem "uses shared libs", aber die passenden libs sind nicht installiert bzw. die neue multiarch-Mimik ist nicht richtig konfiguriert oder so.

[Meillo]

@Meillo:
Wenn man ein strace des Programms auf dem Rechner, auf dem es nicht funktioniert, ausführt, dann erscheint folgende Meldung:
strace ./g3dhexa_F95_R8_Linux_DLR_intel.x
execve("./g3dhexa_F95_R8_Linux_DLR_intel.x", ["./g3dhexa_F95_R8_Linux_DLR_intel"...], [/* 17 vars */] <unfinished ...>
+++ killed by SIGKILL +++
Getötet
Und genau diese Meldung "+++ killed by SIGKILL +++" war mein Topic. Also ich wollte mit den Pluszeichen keine erhöhte Aufmerksamkeit erzeugen.

Dann entschuldige ich mich fuer meine Aenderung. Ich hab's zurueckgefuehrt.

[Leverator]

@cosmac:
Die gebooteten Kernel sind identisch. - Siehe ersten Post. Die beiden Systeme sind jeweils x86_64.

Die einzigen Unterschiede, die noch etwas zur Lösung beitragen könnten sind:
1) Die Software wurde mit Hilfe des Intel Fortran Compilers kompiliert
Und dieser Compiler muss verwendet werden, weil die alten Fortran-Hacks sonst nicht funktionieren.

2) Rechner A hat erheblich weniger Speicherplatz als Rechner B.
(B): 24GB <-> (A): 2GB

Google spuckt ein paar Treffer aus, wenn man "killed by SIGKILL" und intel fortran als Futter verwendet. Bei einigen Treffern wird vermutet, daß diese Fehlermeldung daher kommt, weil das Fortran Programm zu viel Speicher beim Initialisieren auf den Stack packen will (oder so...).
Jedenfalls habe ich versucht, dieses Problem nachzustellen und habe ein Fortranprogramm geschrieben, das so viel Specher für ein 3-dimensionales Array anfordert, sodaß dieses weder in RAM noch in SWAP passt. Dieses ließ sich problemlos kompilieren und starten.
- zumindest mit gfortran.
Der Test mit ifort steht noch aus...


Grüße,
Lev

[Cae]

Wenn gesichert ist, dass die Binary dieselbe ist, sollte man wohl die Umgebung unter die Lupe nehmen, also dpkg -l von beiden Buechsen diffen und mit debsums die Konsistenz sicherstellen.

"Normalerweise" wuerde ich ein SIGSEGV (11) erwarten, wenn ein Programm irgendwie Amok laeuft. Oder dass es mit OOM (out of memory) gekillt wird. Aber es wird direkt mit SIGKILL abgeschossen, das sieht imho nach Absicht aus. Vielleicht irgendein "Trojanerschutz" oder aehnlicher Unfug? SELinux (keine Ahnung, was das tut, wenn es ein Ueberschreitung wittert)? Je nach Paranoialevel kann man auch von einer kompromittierten Maschine ausgehen und das Killen fremder Prozesse fuer den Entdeckungsschutz eines Rootkits halten.

Syslog mit tail -f oder less im Durchlaufmodus betrachten, evlt. komplett /var/log/ mit inotify-irgendwas aus inotify-tools auf Aenderungen untersuchen (die auch mal eine Minute zeitversetzt sein koennen!). Und dann nochmal das Programm starten.

Gruss Cae