viele Programme bringen >killed by SIGKILL<

[heinz]

Hallo Zusammen,

ich hab auf meinem Banana-Pi (raspbian-jessie-mate-bpi-m3-sd-emmc) folgendes Problem:
Wenn ich als "normaluser" angemeldet bin, kann ich viele Standard-Programme nicht nutzen.
Zum Beispiel:
pstree, tar und pico starten nicht.
top, povray und df laufen einwandfrei.

Als Ausgabe kommt nur:

Code: Alles auswählen

bananapi:~ $ pstree
Killed

Strace meint dazu:

Code: Alles auswählen

bananapi:~ $ strace pstree
execve("/usr/bin/pstree", ["pstree"], [/* 17 vars */] <unfinished ...>
+++ killed by SIGKILL +++

Weitere Hinweise:
Als root laufen alle Programme wie sie sollen.
In keiner Log-Datei taucht irgendwas darüber auf.
Datei-Zugriffsrechte sind korrekt.
file zeigt auch keine unterschiede zwischen funktionierenden und nicht funktionierenden.

Bin mit meinem Latein irgendwie am Ende...

Hat einer einen Tipp für mich wo ich weitersuchen könnte?

gruß heinz

[rendegast]

Hast Du vielleicht ein policy-framework laufen?
tomoyo / apparmor / selinux

[heinz]

Hallo rendegast,

erstmal Danke für Deine Antwort.

Hab mal nach den 3 Programmen gesucht (mit find / ... und aptitude ....) und bin nur bei selinux fündig geworden.

Code: Alles auswählen

aptitude search selinux
i   libselinux1                     - SELinux runtime shared libraries

Es gibt auch eine Datei in /etc/selinux/semanage.conf in der aber nicht viel drinsteht:

Code: Alles auswählen

module-store = direct
expand-check=0

Es scheint, keines der genannten Programme ist in funktion.

gruß heinz

[rendegast]

Ist Dein System am Ende mit seinen Ressourcen,
sodaß als "unwichtig" erachtete Prozesse automatisch beendet werden?
Arbeitsspeicher 'free -m'.
oom-killer, sollte wohl Logeinträge geben.

Wie mit einem neu angelegten Benutzer?

Speichertest? ( Bei einem raspbian memtest86?? )
'dmesg'?

swap-Speicher?
Falls keiner vorhanden, mal eine swap-Datei versuchen:

Code: Alles auswählen

dd if=/dev/zero of=/SWAP   bs=1M count=64
chmod 600 /SWAP
mkswap /SWAP
swapon /SWAP

google "raspbian-jessie killed by SIGKILL"
bringt eigentlich nur diesen Thread.

[Meillo]

Seltsam niedrige ulimit-Werte koennten es wohl auch sein, scheint mir aber unwahrscheinlich.

[heinz]

Ist Dein System am Ende mit seinen Ressourcen,
Arbeitsspeicher 'free -m'.

Unwahrscheinlich. Es ist auch direkt nach dem Systemstart so.
Der Speicher (2GB) ist kaum belegt, CPU-Last minimal...

Wie mit einem neu angelegten Benutzer?

Gleicher Effekt.

Speichertest?

Wie gesagt, als root läuft ja alles wie es soll.

'dmesg'?

Nichts...

swap-Speicher?

Der ist sehr klein (100MB) aber vorhanden. (Den hab ich noch nie "benutzt" gesehen...)

Hab noch weitergesucht und wie es für mich aussieht (mit strace) killen sich die Programme selbst???

Hoffe auf weitere Tipps....

gruß heinz

[heinz]

Hallo Meillo,

Seltsam niedrige ulimit-Werte koennten es wohl auch sein

bananapi:~ $ ulimit
unlimited

Gibt es vlt. noch andere Tools, ähnlich wie strace, mit denen man Programme "beobachten" kann?

gruß heinz

[Meillo]

Hallo Meillo,

Seltsam niedrige ulimit-Werte koennten es wohl auch sein

bananapi:~ $ ulimit
unlimited

Es war Absicht, dass ich den Plural verwendet habe: ``ulimit -a''

[Meillo]

pstree, tar und pico starten nicht.
top, povray und df laufen einwandfrei.

Wenn manche immer gehen und manche nie, dann ist die Frage, was der Unterschied zwischen diesen Gruppen ist.

file zeigt auch keine unterschiede zwischen funktionierenden und nicht funktionierenden.

Gibt's vielleicht Unterschiede bei ldd(1)?
Oder liegen sie in unterschiedlichen Verzeichnissen (`which')?
Sind die einen groesser als die anderen?

[heinz]

Es war Absicht, dass ich den Plural verwendet habe: ``ulimit -a''

Sorry...

user@bananapi:~ $ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 12003
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 95
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 12003
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

root@bananapi:~# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 12003
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 12003
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Sieht für mich alles O.K. aus...

gruß heinz

[heinz]

Gibt's vielleicht Unterschiede bei ldd(1)?

Ja, allerdings:

root@bananapi:~# ldd /usr/bin/pstree
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0xb6fb6000)
libtinfo.so.5 => /lib/arm-linux-gnueabihf/libtinfo.so.5 (0xb6f6f000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e32000)
/lib/ld-linux-armhf.so.3 (0xb6fce000)

user@bananapi:~ $ ldd /usr/bin/pstree
not a dynamic executable

file meint:

file /usr/bin/pstree
/usr/bin/pstree: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=2466937bc435f0e60c16d3a929fb7e5ef369c1ca, stripped

Oder liegen sie in unterschiedlichen Verzeichnissen (`which')?

Ein Teil der Programme liegt unter /usr/bin/ ein anderer Teil in /bin/.
Aber es gibt in beiden verzeichnissen Programme die "gehen" und welche die nicht.

Sind die einen groesser als die anderen?

Die PGM-Größe scheint keinen Einfluss zu haben. Es gibt große und kleine die gehen und nicht gehen.

gruß heinz

[Meillo]

Gibt's vielleicht Unterschiede bei ldd(1)?

Ja, allerdings:

root@bananapi:~# ldd /usr/bin/pstree
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0xb6fb6000)
libtinfo.so.5 => /lib/arm-linux-gnueabihf/libtinfo.so.5 (0xb6f6f000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e32000)
/lib/ld-linux-armhf.so.3 (0xb6fce000)

user@bananapi:~ $ ldd /usr/bin/pstree
not a dynamic executable

Hae? Also entweder die Datei ist dynamisch gelinkt oder sie ist statisch gelinkt ... das ist nicht User-abhaengig!

Mach mal ein stat(1) auf die Datei. Dann siehst du anhand der Inode, ob es fuer root und den User die identische Datei ist.

Riecht fuer mich irgendwie nach einer chroot-Umgebung oder etwas aehnlichem fuer den User. Also vielleicht tatsaechlich selinux oder so Zeugs.

[cosmac]

hi,

busybox oder nicht busybox? Aber wie konfiguriert man den Unterschied root/user?

[heinz]

Mach mal ein stat(1) auf die Datei...

Die Ausgabe ist in beiden fällen identisch.

Code: Alles auswählen

bananapi:/# stat /usr/bin/pstree
  File: ‘/usr/bin/pstree’
  Size: 22188           Blocks: 48         IO Block: 4096   regular file
Device: b302h/45826d    Inode: 205264      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)

Riecht fuer mich irgendwie nach einer chroot-Umgebung oder etwas aehnlichem fuer den User.

Vlt. hast Du recht::

user@bananapi:/ $ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w \$\[\033[00m\]

Wie liesse sich das denn richtig feststellen?

Also vielleicht tatsaechlich selinux oder so Zeugs.

Das einzige was ich in dieser Richtung finden konnte ist eine installierte lib von selinux:

libselinux1 - SELinux runtime shared libraries

Es braucht doch aber mehr als diese eine lib um selinux zu betreiben. Oder? (Habs noch nie verwendet...)

Was ich auf meiner Suche im Netz noch gefunden hab:
Der selbe Fehler tritt scheinbar auf, wenn man versucht 32bit Programme auf einem 64bit System zu starten und ein paar libs fehlen.
Da alle Programme (laut file) 32bit sind, ist es vlt. so das als user einige libs nicht gefunden werden?

Zwischendurch mal ein grosses Dankeschön für Deine/Eure Hilfe und Tipps...

gruß heinz

[heinz]

Hallo cosmac,

busybox oder nicht busybox?

nicht busybox! (ist nicht Installiert...)

Danke für den Tipp. Busybox kannte ich noch nicht.
Immer wieder super was man hier im Forum für Software kennenlernt!

gruß heinz

[Cae]

Mach' mal zwei Sessions auf, einmal user, einmal root:

Code: Alles auswählen

user$ tail -f /usr/bin/pstree >/dev/null &

(da sollte eine Job-ID und eine Process ID, im folgenden $PID, rausfallen)

Code: Alles auswählen

root# for f in /proc/$PID/fd/*; do readlink -f "$f"; done

Was kommt raus? (Der Output von lsof -np $PID waere genauso aufschluessig, aber ich mag mich auf moeglichst wenig Drittprogramme verlassen.)

Gruss Cae

[heinz]

Hallo Cae,
Danke für Deine Antwort.

Mach' mal zwei Sessions auf...

Code: Alles auswählen

user$ tail -f /usr/bin/pstree >/dev/null &
[1] 24345

Code: Alles auswählen

root# for f in /proc/24345/fd/*; do readlink -f "$f"; done
/dev/pts/0
/dev/null
/dev/pts/0
/usr/bin/pstree
/proc/24345/fd/anon_inode:inotify

Sieht für mich normal aus...

Gruß heinz

[Cae]

Schade, das sieht unerwartet normal aus. Anhand des Ergebnisses laesst sich a) ein chroot ausschliessen und ebenso b) eventuelle $PATH- oder sonstige Verrenkungen.

Bleibt das Verhalten, wenn du einen neuen Benutzer anlegst und es dort probierst? Falls nein, wird's interessant, dann wuerde ich vergleichen, was da anders ist:

Code: Alles auswählen

root# strace -fo userA su -c /usr/bin/pstree userA

Das Ganze fuer userB wiederholen und anschliessend die beiden Logs vergleichen.

Gruss Cae