top replacement

unull

unull

Nervensäge
Ich bin auf der Suche nach einem FreeBSD-nativem Ersatz fuer top, am besten in Farbe und bunt!

Ich dachte da an sowas wie htop, nur eben ohne linprocfs, denn das scheint momentan leider nicht zu funktionieren.
Auf github bin ich auf utop gestossen, was auch sehr interessant aussieht; ist leider auch wieder fuer Linux.

Ich wuerde es auch eventuell selber versuchen umzuschreiben, aber da tun sich einige Frage auf:

Wie komme ich in FreeBSD an Prozess-Infos ran?
Brauche ich dazu procfs unbedingt oder geht das auch auf anderem Wege?
Und falls ja, hat jemand vielleicht einen Link, der den Unterschied von procfs zu linprocfs verdeutlicht?

Schonmal Danke und viele Gruesse
 
Das von FreeBSD verwendete top(1) ist unixtop[1], was in den meisten klassischen Unixen zum Einsatz kommt. Es spricht über ein systemabhängiges Backend mit dem Kernel. Es erfüllt im Großen und Ganzen seinen Zweck, ist aber nicht bunt und auch nicht sonderlich genau. Eine native Alternative kenne ich nicht, alle mir bekannten sind mehr oder minder grützige Linux-Portierungen.

In der BSD-Familie ist /proc traditionell nur dazu da, Informationen über die einzelnen Prozesse herauszugeben. Unter Linux dient es hingegen als allgemeine Informationsquelle, unter anderem auch für allgemeine Informationen über das System. Sie wollen es zwar in /proc und /sys spalten, aber wirklich erfolgreich sind sie damit bisher nicht. FreeBSDs linprocfs und linsysfs versuchen die beiden zu emulieren, teilweise durch herausgeben richtigter Daten, teilweise durch auffüllen mit Dummywerten.

FreeBSD hat mit 5.0 begonnen /proc endgültig abzuschaffen. Dafür gibt es mehrere Gründe:
- /proc ist langsam, ineffizient und hat sich in der Vergangenheit oft als Sicherheitsrisiko gezeigt.
- /proc ist aus Sicht eines Entwicklers aufwändig bis unangenehm.
- Es gibt bessere Schnittstellen.
Tatsächlich ist in den letzten Jahren der Anteil an Tools die /proc brauchen deutlich gesunken. Im Basissystem war lange Zeit "ps -e" das letzte, seit 9.0 ist es aber nun auch endlich proc-los. Mag sein, dass in den Ports noch welche herumgeistern, aber eigentlich benötigt man kein /proc mehr.

Neue Anwendungen sollten daher keinesfalls auf /proc zurückgreifen. Die Mittel deiner Wahl sind kvm(3) und sysctl(3). Als Beispiel kannst du dich an unixtop orientieren: /usr/src/usr.bin/top/machine.c

1: http://www.unixtop.org/
 
So, nach kurzem Studium von kvm(3) und v.a. kvm_getprocs(3) kriege ich schonmal eine Liste aller Prozesse. Schonmal ein guter Anfang ;)

Spricht irgendwas gegen die Verwendung von ncurses? Ich sehe zwar, dass top(1) nicht ncurses verwendet, werde aber auch nicht schlau draus, womit dort die Anzeige gerendert wird.
 
top rendert wahrscheinlich (ich habe es nun nicht nachgeschaut) "manuell", also mittel Steuerzeichen um den Cursor zu platzieren. Das ist recht elegant, aber auch absolut widerlich zu implementieren, wenn die Sache komplexer wird. Daher würde ich auch zu Curses raten. Allerdings aus dem Basisystem, nicht die Bibliothek aus den Ports. Sollten aber eh weitgehend gleich sein...
 
In /usr/src/sys/sys/user.h (Source) sind in struct kinfo_proc zwei UID's definiert:

Code: 
	uid_t	ki_uid;			/* effective user id */
	uid_t	ki_ruid;		/* Real user id */

Kann mir jemand sagen, worin der Unterschied zwischen real und effective liegt bzw. was fuer 'top' davon relevant ist?
 
Evtl ist eine Davon die unter der der Prozess gestartet wurde und die andere die unter der der Prozess rennt? Ist aber nur geraten.
 
unull schrieb:
In /usr/src/sys/sys/user.h (Source) sind in struct kinfo_proc zwei UID's definiert:

Code: 
	uid_t	ki_uid;			/* effective user id */
	uid_t	ki_ruid;		/* Real user id */

Kann mir jemand sagen, worin der Unterschied zwischen real und effective liegt bzw. was fuer 'top' davon relevant ist?
Zum Vergrößern anklicken....

siehe setuid(2)
 
Danke nochmal fuer alle Antworten!

Es wird schon langsam:
 

Anhänge

  • 2012-03-20-091027_958x1062_scrot.png
    2012-03-20-091027_958x1062_scrot.png
    48,3 KB · Aufrufe: 297
Ich versuche gerade utop auf NetBSD zum Laufen zu bekommen. Ich habe soweit die kvm_* Calls angepasst, scheitere aber am Compilen wegen ncurses (es ist devel/ncurses installiert):

https://gist.github.com/05e1376352db33916eb3

Die Flags aus dem Makefile sind:

Code: 
CFLAGS  = -g -Wall -Wextra -pedantic -std=c99 `/usr/pkg/bin/ncurses5-config --cflags`
LDFLAGS = -g -lncurses -lkvm `/usr/pkg/bin/ncurses5-config --lib`

Jemand ne Idee?
 
NetBSD besitzt ein eigenes curses im Basissystem. Das kannst du auch so verwenden.

Also -lcurses war gemeint, lass den Config Part weg.
 
darktrym schrieb:
NetBSD besitzt ein eigenes curses im Basissystem. Das kannst du auch so verwenden.

Also -lcurses war gemeint, lass den Config Part weg.
Zum Vergrößern anklicken....

Danke, damit sind die ganzen seltsamen Fehler erstmal weg. Allerdings hakt es jetzt bei:

Code: 
cc -g -lcurses -lkvm -o utop main.o machine.o gui.o proc.o util.o
gui.o: In function `showproc':
/home/flo/nfs/utop/gui.c:199: undefined reference to `mvchgat'
gui.o: In function `showprocs':
/home/flo/nfs/utop/gui.c:302: undefined reference to `mvchgat'
*** Error code 1

curs_attr(3x) sagt, dass die Funktion da ist, curses.h ist auch included.

UPDATE: Das war wohl die Manpage von ncurses und es scheint, als ob nur ncurses diese Funktion hat. Also wieder zurück auf Start ;)
 
Zuletzt bearbeitet:
Ok, es baut jetzt. Der Trick sind folgende Flags (wegen ncurses_dll.h):

Code: 
CFLAGS  = -g -Wall -Wextra -pedantic -std=c99 -I/usr/pkg/include/ -I/usr/pkg/include/ncurses
LDFLAGS = -g -lkvm -L/usr/pkg/lib -lncurses

Wenn ich das Programm dann starten will:
Code: 
netbsd$ ./utop
Shared object "libncurses.so.5" not found

Und nochmal UPDATE:

Code: 
CFLAGS  = -g -Wall -Wextra -pedantic -std=c99 -I/usr/pkg/include/ -I/usr/pkg/include/ncurses
LDFLAGS = -g -lkvm -L/usr/pkg/lib -lncurses -Wl,-R/usr/pkg/lib
Das tuts. Phew.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben