Unix/Linux Prozesse nach Aktualität sortieren

R

roeschv

Grünschnabel
Hi,

Habe da ein Problem.

Ich habe aktuell folgende ausgabe:


Und hätte das ganze jetzt so sortiert, dass der Älteste Prozess ganz Oben und der aktuellste ganz Unten steht.

Habe uA folgendes versucht:

ps -ef --sort stime

Aber die Ausgabe sortiert nicht so wie ich will.
Bin schon seit Stunden verzweifelt am suchen.
Für eine Hilfestellung wäre ich sehr dankbar.

Ach ja bevor ichs vergesse:

Linux 2.6.16.60-0.39.3-smp #1 SMP Mon May 11 11:46:34 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux
 
Zuletzt bearbeitet:
Wenn es dir nur auf die Reihenfolge ankommt, könntest du auch nach der PID sortieren, weil die einfach hochgezählt wird. Ansonsten glaube ich, dass du ps -ef --sort etime suchst. Wenn nicht, habe ich dein Problem nicht verstanden.
 
Zuletzt bearbeitet:
Folgende Augabe habe ich bei ps -ef

Code:
apfel35:~ # ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Jun20 ?        00:00:38 init [3]
root         2     1  0 Jun20 ?        00:00:35 [migration/0]
root         3     1  0 Jun20 ?        00:00:06 [ksoftirqd/0]
root         4     1  0 Jun20 ?        00:00:57 [migration/1]
root         5     1  0 Jun20 ?        00:00:00 [ksoftirqd/1]

Jetzt würde ich gerne nach der Spalte STIME sortieren und zwar so dass, das älteste Datum oben steht und das Neueste (Wobei bei Tagesaktuellen Prozessen die Uhrzeit drinsteht)

Bei der Sortierung ps -ef --sort stime oder etime bekomme ich immer noch eine wirre Reihenfolge wobei aber gleiche Timestamps beieinander stehen.
 
Aber ps -ef und ps -ef --sort=etime sortieren doch korrekt. Bei mir zumindest. Das sieht man ja auch an der PID. Die man-page sagt, dass etime dafür da ist, die vergangene Zeit seit dem Prozessstart anzuzeigen/danach zu sortieren. Wieso das bei dir nicht so sein soll, kann ich nicht nachvollziehen. Dein zweites Beispiel tut doch genau das. Stime zeigt doch die verbrauchte Systemzeit an, also wie lange der Prozess den Prozessor belegt hat.
 
Diese Ausgabe bekommen ich:

Er sortiert IMHO nach Pid und nicht nach Datum.
 
Zuletzt bearbeitet:
Der Witz ist ja, dass das das Selbe ist. Prozess-IDs werden einfach hochgezählt. Deswegen hat der Mutterprozess init, der zuerst gestartet wurde, immer die PID 1 und alle später gestarteten Kindprozesse haben höhere Nummern. Der zuletzt gestartete Prozess hat immer die höchste PID. Das siehst du ja auch in der Ausgabe von ps, wenn du mal nach dem ps-Befehl schaust, der die Ausgabe erzeugte. Der hat dann garantiert auch die höchste PID.
 
Ja, soweit klar.

Aber wieso habe ich dann eine Sortierung wo Juni steht, dann kommt Oktober und dann der Juli??

Habe grade noch schnell auf den Kalender geschaut ob die Monate noch so gezählt werden wie ich das im Kopf hab ^_^
 
Okay, das ist ein Problem :)
Was hat der Server (ist doch einer?) denn für eine Uptime, läuft der seit Mai? Wenn ja, kann es sein, dass er bei 8stelligen PIDs von vorne beginnt und dann freie PIDs von vorher beendeten Prozessen wählt. Wieso dann aber auch ps -ef --sort=etime nicht funktioniert, ist mir zu hoch. Sortiert er da auch durcheinander? Da müssen dann andere ran :)
 
Ja 20 Juni kommt hin.

Naja, vielen Dank für deine Hilfe, mal abwarten ob vielleicht jemand mehr weiss.

Zur not schreib ich mir was in Perl.. :-)
 
Meine ps Version bietet noch ps -ef --sort=start_time an. Das könnte man noch probieren.
 
Jetzt müsste mir nur noch jemand den Unterschied von etime und start_time erklären ;)
 
auch noch Frage:

hatte mich auch überfordert, als ich das vorhin las, aber mir fällt bei der manpage immerhin auf:
man ps(1) schrieb:
SORTIERSCHLÜSSEL
Beachten Sie, dass die Werte, die für die Sortierung verwendet werden, interne Werte von ps sind und nicht die Werte, die letztendlich ausgebeben werden. Wenn Sie nach den endgültigen Werten sortieren möchten, pipen Sie die Ausgabe durch sort(1).
  • Benimmt sich --sort wie eine Pipe an sort?
  • Warum steht etime nicht im Abschnitt "SORTIERSCHLÜSSEL" der manpage, start_time aber schon?
    • -> woher beziehen beide ihre Infos?
und das:
Code:
root      2254     1  0 Oct05 ?        00:00:0[color=blue]0[/color] /usr/sbin/console-kit-daemon
101       2320     1  0 Oct05 ?        00:00:0[color=red]1[/color] /usr/sbin/hald --daemon=yes
root      2324  2320  0 Oct05 ?        00:00:0[color=blue]0[/color] hald-runner
Da ist ja die Startsekunde in der Mitte paradox....
 
Der Witz ist ja, dass das das Selbe ist. Prozess-IDs werden einfach hochgezählt. Deswegen hat der Mutterprozess init, der zuerst gestartet wurde, immer die PID 1 und alle später gestarteten Kindprozesse haben höhere Nummern. Der zuletzt gestartete Prozess hat immer die höchste PID. Das siehst du ja auch in der Ausgabe von ps, wenn du mal nach dem ps-Befehl schaust, der die Ausgabe erzeugte. Der hat dann garantiert auch die höchste PID.
Stimmt leider(?) nicht mehr. Als Sicherheitsfeature wurde irgendwann mal eingeführt, daß PIDs zufällig vergeben werden - die höchste PID ist also nicht zwingend der als zuletzt gestartete Prozess.
 
Stimmt leider(?) nicht mehr. Als Sicherheitsfeature wurde irgendwann mal eingeführt, daß PIDs zufällig vergeben werden - die höchste PID ist also nicht zwingend der als zuletzt gestartete Prozess.

Davon höre ich zum ersten Mal und habe es auch noch nie gesehen, jedenfalls nicht mit Bewusstsein. Braucht es dafür eine gesetzte Kernel-Option oder Sicherheitserweiterung (SE-Linux, App Amor...) und wie soll das die Sicherheit erhöhen können?
 
AFAIK ist das inzwischen default - keine Ahnung, ob man es irgendwo schalten kann...

Sicherheit erhöht es, indem dadurch die ProzessIDs nicht vorhersagbar werden, was Exploits erschweren kann - z.B. bei Portscanns. Es gibt etwas Material dazu im Netz, sonderlich viel ist's leider nicht.
 
Davon höre ich zum ersten Mal und habe es auch noch nie gesehen, jedenfalls nicht mit Bewusstsein.
ich auch nicht, das heißt aber nix, ich renne nicht jeder Kernelversion hinterher.

Außerdem verstehe ich die Idee nicht, wenn man es dann doch listen kann mit ps oder sie sogar abschießen kann
Code:
#>kill -9 `pidof sshd`
-> kill(1) hat mehr Optionen als killall(1)

Braucht es dafür eine gesetzte Kernel-Option oder Sicherheitserweiterung (SE-Linux, App Amor...) und wie soll das die Sicherheit erhöhen können?
verstehe ich gerade auch nicht, außerdem definieren SE-Linux und AppArmor doch Regeln für Programme zu deren Laufzeit, die dann ja schon eine PID haben

Die Antwort würde mich auch interessieren

Sicherheit erhöht es, indem dadurch die ProzessIDs nicht vorhersagbar werden, was Exploits erschweren kann - z.B. bei Portscanns.
Portscans scannen soweit ich immer dachte nach Diensten auf Netzwerkports, deren Sinn es ist, diese Dienste entfernt zu nutzen, ohne das dahinter stehende Programm ansprechen zu müssen, weil der Request das überhaupt nicht kennt. Ist :80 offen? Ja / nein! Kommen dabei Header rüber, nach denen man den Server erraten kann? Ja / nein

Wer PIDs abfragen kann, ist schon auf deinem System, dachte ich, und schon lange nicht mehr in Netzwerkprotokollen, wo man Ports scannt.

Irre ich mich da fatal?

Es gibt etwas Material dazu im Netz, sonderlich viel ist's leider nicht.
zeig doch mal
 
Zuletzt bearbeitet:
Ich kann in der Kerneldokumentation auch nichts finden. Das muss bei deren Qualität zwar nichts bedeuten, aber bis mir niemand das Gegenteil beweist, glaube ich es erstmal nicht. Zumal mir Google dazu auch irgendwie nichts Vernünftiges liefert.
Dafür steht in der Kernel-Dokumentation etwas zu start_time, nicht aber zu etime. Wo etime herkommt, ist also irgendwie seltsam.
 

Ähnliche Themen

OpenSuse 12.3 / Tiefschlaf funktioniert nicht

LOG auswertung in Shell | Addieren mit awk bei bestimmter Bedingung

HP PSC 2175 - CUPS druckt nicht

Startx Probleme bei OpenSuse 10.2

Geforce GT 240m - Aspire 5739G - Treiberproblem - 6 faches Bild

Zurück
Oben