Der Provider proc stellt Prüfpunkte für die folgenden Aktivitäten zur Verfügung: Erzeugen und Beenden von Prozessen, Erzeugen und Beenden von LWPs, Ausführen neuer Programmabbilder und Senden sowie Behandeln von Signalen.
Die proc-Prüfpunkte sind in Tabelle 25–1 beschrieben.
Tabelle 25–1 proc-Prüfpunkte
Prüfpunkt |
Beschreibung |
---|---|
create |
Prüfpunkt, der beim Erzeugen eines Prozesses mit fork(2), forkall(2), fork1(2) oder vfork(2) ausgelöst wird. Auf psinfo_t des neuen untergeordneten Prozesses wird mit args[0] gezeigt. Sie können vfork von den anderen fork-Varianten unterscheiden, indem Sie in der pr_flag-Komponente von lwpsinfo_t des den neuen Prozess erzeugenden Threads auf PR_VFORKP prüfen. Sie können fork1 von forkall unterscheiden, indem Sie die pr_nlwp-Komponenten aus psinfo_t (curpsinfo) des übergeordneten sowie aus psinfo_t (args[0]) des untergeordneten Prozesses untersuchen. Da der Prüfpunkt create erst nach der erfolgreichen Erzeugung des Prozesses ausgelöst wird und die LWP-Erzeugung Teil der Erzeugung eines Prozesses ist, wird lwp-create pro LWP ausgelöst, der mit der Prozesserzeugung entsteht, und zwar bevor der Prüfpunkt create für den neuen Prozess ausgelöst wird. |
exec |
Prüfpunkt, der ausgelöst wird, wenn ein Prozess mit einer Variante des exec(2)-Systemaufrufs ein neues Prozessabbild lädt: exec(2), execle(2), execlp(2), execv(2), execve(2), execvp(2). Der Prüfpunkt exec wird ausgelöst, bevor das Prozessabbild geladen wird. Prozessvariablen wie execname und curpsinfo enthalten folglich den Prozessstatus vor dem Laden des Abbilds. Kurz nach der Auslösung des Prüfpunkts exec wird in demselben Thread entweder exec-failure oder exec-success ausgelöst. Auf den Pfad des neuen Prozessabbilds zeigt args[0]. |
exec-failure |
Prüfpunkt, der ausgelöst wird, wenn eine exec(2)-Variante fehlschlägt. Der Prüfpunkt exec-failure wird erst nach der Auslösung des Prüfpunkts exec in demselben Thread ausgelöst. Der Wert von errno(3C) steht in args[0] bereit. |
exec-success |
Prüfpunkt, der ausgelöst wird, wenn eine exec(2)-Variante erfolgreich war. Wie exec-failure wird auch exec-success erst nach der Auslösung des Prüfpunkts exec in demselben Thread ausgelöst. Wenn der Prüfpunkt exec-success ausgelöst wird, enthalten Prozessvariablen wie execname und curpsinfo bereits den Prozessstatus nach dem Laden des neuen Prozessabbilds. |
exit |
Prüfpunkt, der beim Beenden des aktuellen Prozesses ausgelöst wird. Der Grund für die Beendigung, der in Form einer der SIGCHLD siginfo.h(3HEAD)-Codes ausgedrückt wird, ist in args[0] enthalten. |
fault |
Prüfpunkt, der ausgelöst wird, wenn in einem Thread ein Maschinenfehler auftritt. Der Fehlercode (gemäß der Definition in proc(4)) befindet sich in args[0]. Auf die Struktur siginfo des Fehlers wird mit args[1] gezeigt. Nur Fehler, die ein Signal auslösen, können auch den Prüfpunkt fault auslösen. |
lwp-create |
Prüfpunkt, der bei der Erzeugung eines LWP, in der Regel als Folge von thr_create(3C) ausgelöst wird. Auf lwpsinfo_t des neuen Threads wird mit args[0] gezeigt. Auf psinfo_t des Prozesses, der den Thread enthält, wird mit args[1] gezeigt. |
lwp-start |
Prüfpunkt, der innerhalb des Kontexts eines neu erzeugten LWP ausgelöst wird. Der Prüfpunkt lwp-start wird vor der Ausführung etwaiger Anweisungen auf Benutzerebene ausgelöst. Ist der LWP der erste LWP im Prozess, wird zunächst der Prüfpunkt start und anschließend lwp-start ausgelöst. |
lwp-exit |
Prüfpunkt, der ausgelöst wird, wenn ein LWP entweder als Reaktion auf ein Signal oder auf einen ausdrücklichen thr_exit(3C)-Aufruf beendet wird. |
signal-discard |
Prüfpunkt, der ausgelöst wird, wenn ein Signal an einen Single-Threaded-Prozess gesendet und vom Prozess freigegeben (unblock) und ignoriert wird. Unter diesen Bedingungen wird das Signal bei der Generierung verworfen. lwpsinfo_t und psinfo_t des Zielprozesses und Threads sind in args[0] bzw. args[1] enthalten. Die Signalnummer befindet sich in args[2]. |
signal-send |
Prüfpunkt, der beim Senden eines Signals an einen Thread oder Prozess ausgelöst wird. Der Prüfpunkt signal-send wird im Kontext des sendenden Prozesses und Threads ausgelöst. lwpsinfo_t und psinfo_t des Empfängerprozesses und Threads sind in args[0] bzw. args[1] enthalten. Die Signalnummer befindet sich in args[2]. Auf signal-send folgen im empfangenden Prozess und Thread immer signal-handle oder signal-clear. |
signal-handle |
Prüfpunkt, der unmittelbar vor der Behandlung eines Signals durch einen Thread ausgelöst wird. Der Prüfpunkt signal-handle wird im Kontext des Threads ausgelöst, der das Signal behandelt. Die Signalnummer befindet sich in args[0]. In args[1] befindet sich ein Zeiger auf die zum Signal gehörige Struktur siginfo_t. Der Wert von args[1] ist NULL, wenn keine siginfo_t-Struktur existiert oder in der Signalbehandlungsroutine das Flag SA_SIGINFO nicht gesetzt ist. Die Adresse des Signal-Handlers im Prozess ist in args[2] enthalten. |
signal-clear |
Prüfpunkt, der ausgelöst wird, wenn ein anstehendes Signal gelöscht wird, da der Ziel-Thread in sigwait(2), sigwaitinfo(3RT) oder sigtimedwait(3RT) auf das Signal wartete. Unter diesen Bedingungen wird das anstehende Signal gelöscht und die Signalnummer an den Aufrufer zurückgereicht. Die Signalnummer befindet sich in args[0]. signal-clear wird im Kontext des zuvor wartenden Threads ausgelöst. |
start |
Prüfpunkt, der innerhalb des Kontexts eines neu erzeugten Prozesses ausgelöst wird. Der Prüfpunkt start wird vor der Ausführung etwaiger Anweisungen auf Benutzerebene im Prozess ausgelöst. |
Die Argumenttypen für proc-Prüfpunkte sind in Tabelle 25–2 aufgeführt. In Tabelle 25–1 finden Sie eine Beschreibung der Argumente.
Tabelle 25–2 Argumente für proc-Prüfpunkte
Prüfpunkt |
args[0] |
args[1] |
args[2] |
---|---|---|---|
create |
psinfo_t * |
— |
— |
exec |
char * |
— |
— |
exec-failure |
int |
— |
— |
exit |
int |
— |
— |
fault |
int |
siginfo_t * |
— |
lwp-create |
lwpsinfo_t * |
psinfo_t * |
— |
lwp-start |
— |
— |
— |
lwp-exit |
— |
— |
— |
signal-discard |
lwpsinfo_t * |
psinfo_t * |
int |
signal-discard |
lwpsinfo_t * |
psinfo_t * |
int |
signal-send |
lwpsinfo_t * |
psinfo_t * |
int |
signal-handle |
int |
siginfo_t * |
void (*)(void) |
signal-clear |
int |
— |
— |
start |
— |
— |
— |
Einige proc-Prüfpunkte besitzen Argumente des Typs lwpsinfo_t, wobei es sich um eine in proc(4) dokumentierte Struktur handelt. Die Definition der den DTrace-Verbrauchern zur Verfügung stehenden Struktur lwpsinfo_t lautet:
typedef struct lwpsinfo { int pr_flag; /* flags; see below */ id_t pr_lwpid; /* LWP id */ uintptr_t pr_addr; /* internal address of thread */ uintptr_t pr_wchan; /* wait addr for sleeping thread */ char pr_stype; /* synchronization event type */ char pr_state; /* numeric thread state */ char pr_sname; /* printable character for pr_state */ char pr_nice; /* nice for cpu usage */ short pr_syscall; /* system call number (if in syscall) */ int pr_pri; /* priority, high value = high priority */ char pr_clname[PRCLSZ]; /* scheduling class name */ processorid_t pr_onpro; /* processor which last ran this thread */ processorid_t pr_bindpro; /* processor to which thread is bound */ psetid_t pr_bindpset; /* processor set to which thread is bound */ } lwpsinfo_t;
Das Feld pr_flag ist eine Bit-Maske, die den Prozess beschreibende Flags enthält. Diese Flags und ihre Bedeutung sind in Tabelle 25–3 beschrieben.
Tabelle 25–3 pr_flag-Werte
PR_ISSYS |
Der Prozess ist ein Systemprozess. |
PR_VFORKP |
Der Prozess ist der übergeordnete Prozess eines vfork(2)-Unterprozesses. |
PR_FORK |
Der Modus inherit-on-fork des Prozesses ist gesetzt. |
PR_RLC |
Der Modus run-on-last-close des Prozesses ist gesetzt. |
PR_KLC |
Der Modus kill-on-last-close des Prozesses ist gesetzt. |
PR_ASYNC |
Der Modus asynchronous-stop des Prozesses ist gesetzt. |
PR_MSACCT |
Die Mikrostatusabrechnung (microstate accounting) ist im Prozess aktiviert. |
PR_MSFORK |
Die Mikrostatusabrechnung des Prozesses wird bei fork vererbt. |
PR_BPTADJ |
Der Modus breakpoint-adjustment des Prozesses ist gesetzt. |
PR_PTRACE |
Der Modus ptrace(3C)-compatibility des Prozesses ist gesetzt. |
PR_STOPPED |
Der Thread ist ein angehaltener LWP. |
PR_ISTOP |
Der Thread ist ein an einem Ereignis von Interesse angehaltener LWP. |
PR_DSTOP |
Der Thread ist ein LWP, für den eine stop-Direktive in Kraft ist. |
PR_STEP |
Der Thread ist ein LWP, für den eine single-step-Direktive in Kraft ist. |
PR_ASLEEP |
Der Thread ist ein LWP in unterbrechbarem Schlafzustand innerhalb eines Systemaufrufs. |
PR_DETACH |
Der Thread ist ein gesonderter LWP. Informationen hierzu finden Sie unter pthread_create(3C) und pthread_join(3C). |
PR_DAEMON |
Der Thread ist ein Dämon-LWP. Siehe hierzu pthread_create(3C). |
PR_AGENT |
Der Thread ist der Agent-LWP für den Prozess. |
PR_IDLE |
Der Thread ist der Leerlauf-Thread für eine CPU. Es laufen nur dann Leerlauf-Threads auf einer CPU, wenn die Ausführungswarteschlangen für die CPU leer sind. |
Das Feld pr_addr ist die Adresse einer privaten Datenstruktur im Kernel, die den Thread darstellt. Die Datenstruktur ist privat, aber das Feld pr_addr kann für die gesamte Lebensdauer eines Threads als eindeutiges Symbol für diesen verwendet werden.
Das Feld pr_wchan wird gesetzt, wenn sich der Thread an einem Synchronisierungsobjekt schlafen legt. Die Bedeutung des Felds pr_wchan ist der Kernel-Implementierung vorbehalten, aber das Feld kann als eindeutiges Symbol für das Synchronisierungsobjekt verwendet werden.
Das Feld pr_stype wird gesetzt, wenn sich der Thread an einem Synchronisierungsobjekt schlafen legt. Die möglichen Werte für das Feld pr_stype sehen Sie in Tabelle 25–4.
Tabelle 25–4 pr_stype-Werte
SOBJ_MUTEX |
Mutex-Synchronisierungsobjekt für Kernel. Dient zur Serialisierung des Zugriffs auf gemeinsame Datenbereiche im Kernel. In Kapitel 18Der Provider lockstat und mutex_init(9F) finden Sie ausführliche Informationen zu Mutex-Synchronisierungsobjekten für den Kernel. |
SOBJ_RWLOCK |
Leser/Schreiber-Synchronisierungsobjekt für Kernel. Dient zum Synchronisieren des Zugriffs auf gemeinsame Objekte im Kernel, die mehrere Leser gleichzeitig oder einen einzigen Schreiber zulassen können. In ·Kapitel 18Der Provider lockstat und rwlock(9F) finden Sie ausführliche Informationen zu Leser/Schreiber-Synchronisierungsobjekten für den Kernel. |
SOBJ_CV |
Bedingungsvariablen-Synchronisierungsobjekt. Eine Bedingungsvariable ist darauf ausgerichtet, auf unbestimmte Zeit darauf zu warten, dass eine bestimmte Bedingung eintritt. Bedingungsvariablen dienen in der Regel zum Synchronisieren anderer Vorgänge als den Zugriffen auf gemeinsame Datenbereiche und stellen den Mechanismus dar, der allgemein verwendet wird, wenn ein Prozess einen programmgesteuerten Wartezustand auf unbestimmte Zeit annimmt. Dabei handelt es sich beispielsweise um das Blockieren in poll(2), pause(2), wait(3C) usw. |
SOBJ_SEMA |
Semaphoren-Synchronisierungsobjekt. Ein Allzweck-Synchronisierungsobjekt, das, wie auch Bedingungsvariablenobjekte, keinen Besitz kennt. Da der Aspekt des Besitzes zum Implementieren der Prioritätsvererbung im Solaris-Kernel erforderlich ist, verbietet das Fehlen dieses Aspekts in Semaphorenobjekten eine weite Verbreitung dieser Objekte. Ausführliche Informationen finden Sie im Abschnitt semaphore(9F). |
SOBJ_USER |
Ein Synchronisierungsobjekt auf Benutzerebene Sämtliche Blockierungen von Synchronisierungsobjekten auf Benutzerebene werden mit SOBJ_USER-Synchronisierungsobjekten behandelt. Zu den Synchronisierungsobjekten auf Benutzerebene gehören die mit mutex_init(3C), sema_init(3C), rwlock_init(3C), cond_init(3C) und deren POSIX-Pendants erzeugten Objekte. |
SOBJ_USER_PI |
Ein Synchronisierungsobjekt auf Benutzerebene, das die Prioritätsvererbung implementiert. Einige Synchronisierungsobjekte auf Benutzerebene, die zusätzliche Benutzerinformationen bieten, ermöglichen die Prioritätsvererbung. So kann beispielsweise für Mutex-Objekte, die mit pthread_mutex_init(3C) erzeugt wurden, anhand von pthread_mutexattr_setprotocol(3C) die Prioritätsvererbung erreicht werden. |
SOBJ_SHUTTLE |
Ein Shuttle-Synchronisierungsobjekt Shuttle-Objekte dienen zum Implementieren von Doors. Näheres hierzu siehe door_create(3DOOR). |
Das Feld pr_state wird auf einen der Werte in Tabelle 25–5 gesetzt. In Klammern sehen Sie das entsprechende Zeichen, auf das das Feld pr_sname gesetzt wird.
Tabelle 25–5 pr_state-Werte
SSLEEP (S) |
Der Thread schläft. Der Prüfpunkt sched:::sleep wird ausgelöst, unmittelbar bevor der Status eines Threads in SSLEEP übergeht. |
SRUN (R) |
Der Thread ist lauffähig, läuft aber derzeit nicht. Der Prüfpunkt sched:::enqueue wird ausgelöst, unmittelbar bevor der Status eines Threads in SRUN übergeht. |
SZOMB (Z) |
Der Thread ist ein Zombie-LWP. |
SSTOP (T) |
Der Thread wurde entweder durch eine explizite proc(4)-Direktive oder einen anderen Anhaltemechanismus angehalten. |
SIDL (I) |
Der Thread befindet sich in einem Zwischenstatus der Prozesserzeugung. |
SONPROC (O) |
Der Thread läuft auf einer CPU. Der Prüfpunkt sched:::on-cpu wird im Kontext des SONPROC-Threads kurz nach dem Übergang des Thread-Status in SONPROC ausgelöst. |
Einige proc-Prüfpunkte besitzen ein Argument des Typs psinfo_t, wobei es sich um eine in proc(4) dokumentierte Struktur handelt. Die den DTrace-Verbrauchern zur Verfügung stehende Definition der Struktur psinfo_t lautet:
typedef struct psinfo { int pr_nlwp; /* number of active lwps in the process */ pid_t pr_pid; /* unique process id */ pid_t pr_ppid; /* process id of parent */ pid_t pr_pgid; /* pid of process group leader */ pid_t pr_sid; /* session id */ uid_t pr_uid; /* real user id */ uid_t pr_euid; /* effective user id */ gid_t pr_gid; /* real group id */ gid_t pr_egid; /* effective group id */ uintptr_t pr_addr; /* address of process */ dev_t pr_ttydev; /* controlling tty device (or PRNODEV) */ timestruc_t pr_start; /* process start time, from the epoch */ char pr_fname[PRFNSZ]; /* name of execed file */ char pr_psargs[PRARGSZ]; /* initial characters of arg list */ int pr_argc; /* initial argument count */ uintptr_t pr_argv; /* address of initial argument vector */ uintptr_t pr_envp; /* address of initial environment vector */ char pr_dmodel; /* data model of the process */ taskid_t pr_taskid; /* task id */ projid_t pr_projid; /* project id */ poolid_t pr_poolid; /* pool id */ zoneid_t pr_zoneid; /* zone id */ } psinfo_t;
Das Feld pr_dmodel wird entweder auf PR_MODEL_ILP32 (bezeichnet einen 32-Bit-Prozess) oder auf PR_MODEL_LP64 (bezeichnet einen 64-Bit-Prozess) gesetzt.
Der Prüfpunkt exec stellt ein einfaches Mittel dar, um festzustellen, welche Programme von wem ausgeführt werden. Das nächste Beispiel veranschaulicht dies:
#pragma D option quiet proc:::exec { self->parent = execname; } proc:::exec-success /self->parent != NULL/ { @[self->parent, execname] = count(); self->parent = NULL; } proc:::exec-failure /self->parent != NULL/ { self->parent = NULL; } END { printf("%-20s %-20s %s\n", "WHO", "WHAT", "COUNT"); printa("%-20s %-20s %@d\n", @); }
Wenn das Beispielskript kurz auf einer Build-Maschine ausgeführt wird, erhalten wir eine ähnliche Ausgabe wie in folgendem Beispiel:
# dtrace -s ./whoexec.d ^C WHO WHAT COUNT make.bin yacc 1 tcsh make 1 make.bin spec2map 1 sh grep 1 lint lint2 1 sh lint 1 sh ln 1 cc ld 1 make.bin cc 1 lint lint1 1 sh lex 1 make.bin mv 2 sh sh 3 sh make 3 sh sed 4 sh tr 4 make make.bin 4 sh install.bin 5 sh rm 6 cc ir2hf 33 cc ube 33 sh date 34 sh mcs 34 cc acomp 34 sh cc 34 sh basename 34 basename expr 34 make.bin sh 87 |
Wenn Sie wissen möchten, wie lange Programme zwischen Erzeugung und Ende laufen, können Sie wie folgt die Prüfpunkte start und exit aktivieren:
proc:::start { self->start = timestamp; } proc:::exit /self->start/ { @[execname] = quantize(timestamp - self->start); self->start = 0; }
Wenn Sie das Beispielskript einige Sekunden lang auf dem Build-Server ausführen, erhalten Sie eine ähnliche Ausgabe wie diese:
# dtrace -s ./progtime.d dtrace: script './progtime.d' matched 2 probes ^C ir2hf value ------------- Distribution ------------- count 4194304 | 0 8388608 |@ 1 16777216 |@@@@@@@@@@@@@@@@ 14 33554432 |@@@@@@@@@@ 9 67108864 |@@@ 3 134217728 |@ 1 268435456 |@@@@ 4 536870912 |@ 1 1073741824 | 0 ube value ------------- Distribution ------------- count 16777216 | 0 33554432 |@@@@@@@ 6 67108864 |@@@ 3 134217728 |@@ 2 268435456 |@@@@ 4 536870912 |@@@@@@@@@@@@ 10 1073741824 |@@@@@@@ 6 2147483648 |@@ 2 4294967296 | 0 acomp value ------------- Distribution ------------- count 8388608 | 0 16777216 |@@ 2 33554432 | 0 67108864 |@ 1 134217728 |@@@ 3 268435456 | 0 536870912 |@@@@@ 5 1073741824 |@@@@@@@@@@@@@@@@@@@@@@@@@ 22 2147483648 |@ 1 4294967296 | 0 cc value ------------- Distribution ------------- count 33554432 | 0 67108864 |@@@ 3 134217728 |@ 1 268435456 | 0 536870912 |@@@@ 4 1073741824 |@@@@@@@@@@@@@@ 13 2147483648 |@@@@@@@@@@@@ 11 4294967296 |@@@ 3 8589934592 | 0 sh value ------------- Distribution ------------- count 262144 | 0 524288 |@ 5 1048576 |@@@@@@@ 29 2097152 | 0 4194304 | 0 8388608 |@@@ 12 16777216 |@@ 9 33554432 |@@ 9 67108864 |@@ 8 134217728 |@ 7 268435456 |@@@@@ 20 536870912 |@@@@@@ 26 1073741824 |@@@ 14 2147483648 |@@ 11 4294967296 | 3 8589934592 | 1 17179869184 | 0 make.bin value ------------- Distribution ------------- count 16777216 | 0 33554432 |@ 1 67108864 |@ 1 134217728 |@@ 2 268435456 | 0 536870912 |@@ 2 1073741824 |@@@@@@@@@ 9 2147483648 |@@@@@@@@@@@@@@@ 14 4294967296 |@@@@@@ 6 8589934592 |@@ 2 17179869184 | 0 |
Vielleicht interessiert Sie nicht die Ausführungszeit eines bestimmten Prozesses, sondern einzelner Threads. Das folgende Beispiel zeigt, wie Sie diese Dauer mit den Prüfpunkten lwp-start und lwp-exit ermitteln können:
proc:::lwp-start /tid != 1/ { self->start = timestamp; } proc:::lwp-exit /self->start/ { @[execname] = quantize(timestamp - self->start); self->start = 0; }
Wenn Sie das Beispielskript auf einem NFS- und Kalenderserver ausführen, erhalten Sie eine ähnliche Ausgabe wie diese:
# dtrace -s ./lwptime.d dtrace: script './lwptime.d' matched 3 probes ^C nscd value ------------- Distribution ------------- count 131072 | 0 262144 |@ 18 524288 |@@ 24 1048576 |@@@@@@@ 75 2097152 |@@@@@@@@@@@@@@@@@@@@@@@ 245 4194304 |@@ 22 8388608 |@@ 24 16777216 | 6 33554432 | 3 67108864 | 1 134217728 | 1 268435456 | 0 mountd value ------------- Distribution ------------- count 524288 | 0 1048576 |@ 15 2097152 |@ 24 4194304 |@@@ 51 8388608 |@ 17 16777216 |@ 24 33554432 |@ 15 67108864 |@@@@ 57 134217728 |@ 28 268435456 |@ 26 536870912 |@@ 39 1073741824 |@@@ 45 2147483648 |@@@@@ 72 4294967296 |@@@@@ 77 8589934592 |@@@ 55 17179869184 | 14 34359738368 | 2 68719476736 | 0 automountd value ------------- Distribution ------------- count 1048576 | 0 2097152 | 3 4194304 |@@@@ 146 8388608 | 6 16777216 | 6 33554432 | 9 67108864 |@@@@@ 203 134217728 |@@ 87 268435456 |@@@@@@@@@@@@@@@ 534 536870912 |@@@@@@ 223 1073741824 |@ 45 2147483648 | 20 4294967296 | 26 8589934592 | 20 17179869184 | 19 34359738368 | 7 68719476736 | 2 137438953472 | 0 iCald value ------------- Distribution ------------- count 8388608 | 0 16777216 |@@@@@@@ 20 33554432 |@@@ 9 67108864 |@@ 8 134217728 |@@@@@ 16 268435456 |@@@@ 11 536870912 |@@@@ 11 1073741824 |@ 4 2147483648 | 2 4294967296 | 0 8589934592 |@@ 8 17179869184 |@ 5 34359738368 |@ 4 68719476736 |@@ 6 137438953472 |@ 4 274877906944 | 2 549755813888 | 0 |
Mit dem Prüfpunkt signal-send lassen sich, wie in folgendem Beispiel demonstriert, der sendende und der empfangende Prozess eines Signals ermitteln:
#pragma D option quiet proc:::signal-send { @[execname, stringof(args[1]->pr_fname), args[2]] = count(); } END { printf("%20s %20s %12s %s\n", "SENDER", "RECIPIENT", "SIG", "COUNT"); printa("%20s %20s %12d %@d\n", @); }
Die Ausführung dieses Skripts erzeugt eine Ausgabe wie in folgendem Beispiel:
# dtrace -s ./sig.d ^C SENDER RECIPIENT SIG COUNT xterm dtrace 2 1 xterm soffice.bin 2 1 tr init 18 1 sched test 18 1 sched fvwm2 18 1 bash bash 20 1 sed init 18 2 sched ksh 18 15 sched Xsun 22 471 |
Der Provider proc beschreibt die verschiedenen Stabilitäten anhand des DTrace-Stabilitätsmechanismus gemäß der folgenden Tabelle. Weitere Informationen zum Stabilitätsmechanismus finden Sie in Kapitel 39Stabilität.
Element |
Namensstabilität |
Datenstabilität |
Abhängigkeitsklasse |
---|---|---|---|
Provider |
Evolving |
Evolving |
ISA |
Modul |
Private |
Private |
Unknown |
Funktion |
Private |
Private |
Unknown |
Name |
Evolving |
Evolving |
ISA |
Argumente |
Evolving |
Evolving |
ISA |