Programme gewaltsam beenden

[Zephyrus]

Moin,

ihr kennt das sicher auch, selten aber es kommt vor. Ein Programm hängt sich unter Linux mal richtig weg und man kriegt es nicht geschlossen. Wie kriegt man nun (z.B.) per Konsole raus, welche ProzessID das Programm hat (z.B. Mplayer) und wie lautet dann der Befehl um es quasi gewaltsam zu beenden?

Oder wie macht ihr sowas?

[Stanislaus]

Moin, moin!

ps -ax | grep mplayer

ps = process list
ax weiß ich nicht genau listet aber auf jeden Fall alle Prozesse auf.
Und per grep Programmname findest Du den gewünschten Prozess.

Dann einfach "kill pid" oder "killall -9 programmname"

Bis neulich ...

[Thomas Engelke]

Hey, nicht so einfach mit dem Brecheisen rangehen.

1. Ein Programm stürzt ja nicht aus reiner Langeweile ab. Ab in's Readme. Beta/Alpha/0.x-Version? Kein Wunder.
2. ps ax|grep <progname>
3. kill -SIGHUP <pid>
4. Wenn 3. nicht hilft: kill <pid>
5. Wenn 4. nicht hilft: kill -9 <pid>
6. Wenn 5. nicht hilft: Mutterprozeß ist abgestürzt. Prozeßabhängigkeiten per ps checken (man ps sollte Aufschluß geben).
7. Problem reproduzierbar? Bugreport erstellen.

Programme sind wie Frauen. Man muß sie sanft behandeln und ein Verständnis für sie entwickeln. Dann gedeien sie prächtig :D

AD!

[Zephyrus]

hi, danke.
ich weiss ja warum er abgestürzt ist und ich weiss auch wie ich das reparieren, ich weiss nur nicht wie ich den jetzt beenden konnte :)
nun weiss ich es ja, thx :D

Edit:
Schritt 2. und 3. von Thomas haben ausgereicht, merci :-)

[sepp2k]

Original geschrieben von Thomas Engelke
Prozeßabhängigkeiten per ps checken
oder per pstree

[cane]

Wenn Du unter X arbeitest gibt es auch Proggrämchen für sowas - z.B. Xkill unter KDE... Das Programm legst Du dir auf ein Tastenkürzel und schon brauchst Du nur noch das Tastenkürzel einzugeben und das böse Programm anzuclicken.



Programme sind wie Frauen. Man muß sie sanft behandeln und ein Verständnis für sie entwickeln. Dann gedeien sie prächtig

Full ACK ;)

cane

[sepp2k]

Original geschrieben von cane
z.B. Xkill unter KDE
:confused:
xkill ist doch kein KDE-Programm. Das gehört zu XFree

[Jorge]

Original geschrieben von Thomas Engelke
6. Wenn 5. nicht hilft: Mutterprozeß ist abgestürzt. Prozeßabhängigkeiten per ps checken (man ps sollte Aufschluß geben).


Das geht schön mit ps:



thsfs-lx:~ # ps ax -H
PID TTY STAT TIME COMMAND
6 ? SW 5:56 [kupdated]
5 ? SW 0:00 [bdflush]
4 ? SW 3:39 [kswapd]
3 ? SWN 0:04 [ksoftirqd_CPU0]
1 ? S 0:04 init [3]
2 ? SW 0:00 [keventd]
7 ? SW 0:00 [kreiserfsd]
374 ? S 11:27 /usr/sbin/sshd
22638 ? S 0:00 /usr/sbin/sshd
22639 pts/0 S 0:00 -bash
22661 pts/0 R 0:00 ps ax -H
385 ? S 21:12 /sbin/syslogd
388 ? S 2:44 /sbin/klogd -c 1
399 ? S 0:00 /sbin/portmap
524 ? S 0:00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue
537 ? S 0:23 sendmail: accepting connections
541 ? S 0:00 /usr/sbin/cron
548 tty4 S 0:00 /sbin/mingetty tty4
549 tty5 S 0:00 /sbin/mingetty tty5
550 tty6 S 0:00 /sbin/mingetty tty6
650 ? S 0:00 /opt/samba/sbin/smbd -D
2059 ? S 0:03 /opt/samba/sbin/smbd -D
27307 ? S 0:04 /opt/samba/sbin/smbd -D
4530 ? S 0:00 /opt/samba/sbin/smbd -D
20913 ? S 0:00 /opt/samba/sbin/smbd -D
10012 ? S 0:02 /opt/samba/sbin/smbd -D
652 ? S 4:01 /opt/samba/sbin/nmbd -D
7761 ? S 0:00 /opt/bind/sbin/named
7762 ? S 0:00 /opt/bind/sbin/named
7763 ? S 9:11 /opt/bind/sbin/named
7764 ? S 0:00 /opt/bind/sbin/named
7765 ? S 2:11 /opt/bind/sbin/named
9925 ? S 10:55 /opt/snmp/sbin/snmpd -c /opt/snmp/share/snmp/snmpd.conf
20671 ? S 0:00 /usr/sbin/inetd
21112 tty3 S 0:00 /sbin/mingetty tty3
11939 tty1 S 0:00 /sbin/mingetty --noclear tty1
9603 tty2 S 0:00 /sbin/mingetty tty2
30921 ? S 0:00 /bin/sh /bin/safe_mysqld --user=root
30943 ? S 0:03 /media/samba/mysql/libexec/mysqld --basedir=/media/samba/mysql --datadir=/media/samba/mysql/var
30945 ? S 0:04 /media/samba/mysql/libexec/mysqld --basedir=/media/samba/mysql --datadir=/media/samba/mysql/v
30946 ? S 2:39 /media/samba/mysql/libexec/mysqld --basedir=/media/samba/mysql --datadir=/media/samba/mysql
18582 ? S 0:00 /usr/local/apache2/bin/httpd -k start
18583 ? S 1:15 /usr/local/apache2/bin/httpd -k start
18584 ? S 1:15 /usr/local/apache2/bin/httpd -k start
18585 ? S 1:21 /usr/local/apache2/bin/httpd -k start
18586 ? S 1:20 /usr/local/apache2/bin/httpd -k start
18587 ? S 1:07 /usr/local/apache2/bin/httpd -k start
18588 ? S 1:27 /usr/local/apache2/bin/httpd -k start
18595 ? S 1:11 /usr/local/apache2/bin/httpd -k start
19828 ? S 1:19 /usr/local/apache2/bin/httpd -k start
24158 ? S 1:01 /usr/local/apache2/bin/httpd -k start
thsfs-lx:~ #

pstree geht zwar auch, obiges finde ich persönlich übersichtlicher.

[zander]

Inwiefern ist es vorteilhaft, einem Prozess zunächst ein SIGHUP zu senden, bevor man es mit SIGTERM und SIGKILL versucht? Wieso kann man aus der Tatsache, daß SIGKILL keine Wirkung zeigt, folgern, daß der übergeordnete Prozess abgestürzt ist?

[Thomas Engelke]

Original geschrieben von Jorge
pstree geht zwar auch, obiges finde ich persönlich übersichtlicher.

Ich auch. Danke Jorge. Auch gleich dazugelernt: Es gibt doch einen "code"-Tag im Forum. Interessant.

AD!

[cane]

xkill ist doch kein KDE-Programm. Das gehört zu XFree

Wußte ich nicht - hätte es mir aber denken können - es heißt ja Xkill und nicht Kkill;)

mfg
cane

[Thomas Engelke]

Original geschrieben von zander
Inwiefern ist es vorteilhaft, einem Prozess zunächst ein SIGHUP zu senden, bevor man es mit SIGTERM und SIGKILL versucht? Wieso kann man aus der Tatsache, daß SIGKILL keine Wirkung zeigt, folgern, daß der übergeordnete Prozess abgestürzt ist?

Nunja, ich mach' das immer so. Ich empfinde es als aufschlußreich, die Reaktion eines Programmes auf SIGHUP zu beobachten, bevor ich härtere Methoden anwende. Sollte es reagieren, wird es sich frisch neu starten - fein. Tut es das nicht -> Fallback. Was das SIGKILL angeht, so habe ich diese Schlußfolgerung gestern in einem Thread gelesen und fand sie einleuchtend. Wenn du mehr oder korrigierende Informationen beherbergst, immer her damit.

AD!

[zander]

Für den von Dir genannten Anwendungszweck macht SIGHUP Sinn, es wird aber, je nach Anwendung, möglicherweise nicht den von Zephyrus gewünschten Effekt haben. Wenn SIGKILL keine Wirkung mehr zeigt, so liegt ein schwerwiegenderes Problem vor als ein defektes Elternteil.

[Thomas Engelke]

Original geschrieben von zander
... Wenn SIGKILL keine Wirkung mehr zeigt, so liegt ein schwerwiegenderes Problem vor als ein defektes Elternteil.

Könntest du mal ein paar Beispiele bringen? Oder eine Quelle angeben? Interessiert mich mal.

Danke,

AD!

Edit: Fällt mir erst jetzt auf. Das impliziert, das ein Abschießen eines Childs mittels harter kill-Methodik versucht, auch den Parent Process zu killen. Deshalb bringt es nix, den Elternteil zu betrachten? Oder folgere ich da falsch?

[zander]

Zu diesem Schluß würde man kommen müssen, nähme man an, daß das Problem bei mißachteten SIGKILL Signalen bei den übergeordneten Prozessen liegt. Das ist aber nicht so; versuche z.B. einmal einen der Prozesse via SIGKILL zu beenden, der als unmittelbar übergeordneten Prozess init hat: Du wirst feststellen, daß init sich davon unbeeindruckt zeigt. Natürlich gibt es auch Beispiele für Prozesse, die sich bei Ableben ihrer Kinder dem Freitod hingeben. ;)

Reagiert ein Prozess nicht mehr auf SIGKILL, so hängt das mit Problemen auf Kernelebene zusammen (also mit Problemen während vom betroffenen Prozess ausgeführten Systemrufen), in der Regel mit Fehlfunktionen von Treibern; welche Probleme das konkret sind kann sehr unterschiedlich sein.

[Jasper]

Original geschrieben von Thomas Engelke
Könntest du mal ein paar Beispiele bringen? Oder eine Quelle angeben? Interessiert mich mal.


ist eigentlich sehr einfach. SIGKILL kann von userprozessen nicht abgefangen werden, d.h. ein SIGKILL schlägt IMMER durch. es gibt 2 ausnahmen: prozesse mit status Z oder D.
Z sind zombies, d.h. die prozesse sind bereits tot stehen aber noch in ter prozesstabelle rum und warten darauf, dass der parentprozess den status abholt. zonbies sind harmlos, weil sie keine resourcen ausser den platz in der prozesstabelle beanspruchen.
D sind prozesse, die nicht unterbrochen werden können. das passiert nur, wenn die prozesse auf die rückkehr eines systemcalls warten, bspw. ioclt() o.ä. systemcalls können nicht abgebrochen werden, ergo kann ein userprozess, solange er auf die rückkehr wartet, nicht abgebrochen werden. wenn prozesse im status D hängenbleiben, deutet das auf schwerwiegende probleme hin (kernel-problem, treiberproblem, hardwareproblem).


-j