Chapitre 25 Fournisseur proc
Le fournisseur proc propose des sondes relevant des activités suivantes : création et fin de processus, création et fin de LWP, exécution d'images de nouveau programme et envoi et gestion de signaux.
Sondes
Les sondes proc sont décrites dans le Tableau 25–1.
Tableau 25–1 Sondes proc|
Sonder |
Description |
|---|---|
|
create |
Sonde se déclenchant lors de la création d'un processus à l'aide de fork(2), forkall(2), fork1(2) ou vfork(2). Le psinfo_t correspondant au nouveau processus enfant est indiqué par args[0]. Vous pouvez différencier vfork des autres variantes fork en vérifiant PR_VFORKP dans l'élément pr_flag du thread de fork lwpsinfo_t. Vous pouvez différencier fork1 de forkall en étudiant les membres pr_nlwp de psinfo_t du processus parent (curpsinfo) et psinfo_t du processus enfant (args[0]). La sonde create ne se déclenchant qu'une fois le processus créé et étant donné que la création LWP fait partie de la création d'un processus, lwp-create ne se déclenchera que pour un ou des LWP créés au moment de la création d'un processus avant que la sonde create ne se déclenche pour le nouveau processus. |
|
exec |
Sonde se déclenchant si un processus charge une image de nouveau processus avec une variante de l'appel système exec(2) : exec(2), execle(2), execlp(2), execv(2), execve(2), execvp(2). La sonde exec se déclenche avant le chargement de l'image de processus. Des variables de processus comme execname et curpsinfo contiennent donc l'état du processus avant le chargement de l'image. Suite au déclenchement de la sonde exec, la sonde exec-failure ou exec-success se déclenche dans le même thread. Le chemin d'accès à l'image du nouveau processus est indiqué par args[0]. |
|
exec-failure |
Sonde se déclenchant lors de l'échec d'une variante exec(2). La sonde exec-failure ne se déclenche qu'après le déclenchement de la sonde exec dans le même thread. La valeur errno(3C) est indiquée dans args[0]. |
|
exec-success |
Sonde se déclenchant lors de la réussite d'une variante exec(2). Comme la sonde exec-failure, exec-success ne se déclenche qu'après le déclenchement de la sonde exec dans le même thread. Au moment du déclenchement de la sonde exec-success, des variables de processus comme execname et curpsinfo contiennent l'état du processus après le chargement de l'image du nouveau processus. |
|
exit |
Sonde se déclenchant lors de la sortie du processus en cours. La raison, qui est exprimée par l'un des codes SIGCHLD siginfo.h(3HEAD), est contenue dans args[0]. |
|
fault |
Sonde se déclenchant lorsqu'un thread rencontre une panne machine. Le code de la panne (tel que défini dans proc(4)) se trouve dans args[0]. La structure siginfo correspondant à la panne est indiquée par args[1]. Seules les pannes accompagnées d'un signal peuvent déclencher la sonde fault. |
|
lwp-create |
Sonde se déclenchant lors de la création d'un LWP, résultant généralement de thr_create(3C). Le lwpsinfo_t correspondant au nouveau thread est indiqué par args[0]. psinfo_t du processus contenant le thread est indiqué par args[1]. |
|
lwp-start |
Sonde se déclenchant dans le cadre d'un nouveau LWP. La sonde lwp-start se déclenche avant l'exécution d'une quelconque instruction au niveau utilisateur. Si le LWP est le premier du processus, la sonde start se déclenche, suivie de lwp-start. |
|
lwp-exit |
Sonde se déclenchant lors de la sortie d'un LWP, en raison d'un signal ou d'un appel explicite de thr_exit(3C). |
|
signal-discard |
Sonde se déclenchant lorsqu'un signal est envoyé à un processus à un seul thread. Le signal n'est pas bloqué et est ignoré par le processus. Dans ces conditions, le signal est ignoré à la génération. Les lwpsinfo_t et psinfo_t du processus cible et le thread se trouvent dans args[0] et args[1], respectivement. Le numéro de signal est indiqué dans args[2]. |
|
signal-send |
Sonde se déclenchant lorsqu'un signal est envoyé à un thread ou un processus. La sonde signal-send se déclenche en cas d'envoi du processus ou du thread. Les lwpsinfo_t et psinfo_t du processus et du thread de réception se trouvent dans args[0] et args[1], respectivement. Le numéro de signal est indiqué dans args[2]. signal-send est toujours suivi de signal-handle ou de signal-clear dans le processus et le thread de réception. |
|
signal-handle |
Sonde se déclenchant immédiatement après la gestion d'un signal par un thread. La sonde signal-handle se déclenche en cas de gestion du signal par le thread. Le numéro de signal est indiqué dans args[0]. Un pointeur vers la structure siginfo_t correspondant au signal est indiqué dans args[1]. La valeur de args[1] si aucune structure siginfo_t n'est présente ou si l'indicateur SA_SIGINFO du gestionnaire de signaux n'est pas défini. L'adresse du gestionnaire de signaux du processus est indiquée dans args[2]. |
|
signal-clear |
Sonde se déclenchant lorsqu'un signal en attente est effacé car le thread cible attendait le signal dans sigwait(2), sigwaitinfo(3RT) ou sigtimedwait(3RT). Dans ces conditions, le signal en attente est effacé et le numéro de signal est renvoyé à l'appelant. Le numéro de signal est indiqué dans args[0]. signal-clear se déclenche dans le cadre du thread initial en attente. |
|
start |
Sonde se déclenchant dans le cadre d'un nouveau processus. La sonde start se déclenche avant l'exécution d'une quelconque instruction au niveau utilisateur dans le processus. |
Arguments
Les types d'argument des sondes proc sont répertoriés dans le Tableau 25–2. Les arguments sont décrits dans le Tableau 25–1.
Tableau 25–2 Arguments de sonde proc|
Sonder |
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 |
— |
— |
— |
lwpsinfo_t
Plusieurs sondes proc comprennent des arguments du type lwpsinfo_t, structure abordée dans proc(4). La définition de la structure lwpsinfo_t, telle qu'accessible aux clients DTrace, est la suivante :
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;
Le champ pr_flag est un masque contenant des indicateurs décrivant le processus. Ces indicateurs et leur signification sont décrits dans le Tableau 25–3.
Tableau 25–3 Valeurs de pr_flag|
PR_ISSYS |
Le processus est un processus système. |
|
PR_VFORKP |
Le processus est le parent d'un enfant vfork(2). |
|
PR_FORK |
Le processus est défini en mode d'héritage fork. |
|
PR_RLC |
Le processus est défini en mode d'exécution à la dernière fermeture. |
|
PR_KLC |
Le processus est défini en mode de destruction à la dernière fermeture. |
|
PR_ASYNC |
Le processus est défini en mode d'arrêt asynchrone. |
|
PR_MSACCT |
Le processus est activé en gestion microscopique. |
|
PR_MSFORK |
La gestion microscopique du processus est héritée de fork. |
|
PR_BPTADJ |
Le processus est défini en mode d'ajustement du point d'arrêt. |
|
PR_PTRACE |
Le processus est défini en mode de compatibilité ptrace(3C). |
|
PR_STOPPED |
Le thread est un LWP arrêté. |
|
PR_ISTOP |
Le thread est un LWP arrêté en cas d'événement intéressant. |
|
PR_DSTOP |
Le thread est un LWP disposant d'une directive d'arrêt en vigueur. |
|
PR_STEP |
Le thread est un LWP disposant d'une directive d'étape unique en vigueur. |
|
PR_ASLEEP |
Le thread est un LWP en sommeil interruptible dans un appel système. |
|
PR_DETACH |
Le thread est un LWP détaché. Reportez-vous aux pages Web de pthread_create(3C) et pthread_join(3C). |
|
PR_DAEMON |
Le thread est un LWP démon. Reportez-vous à la page Web de pthread_create(3C). |
|
PR_AGENT |
Le thread est le LWP agent du processus. |
|
PR_IDLE |
Le thread est un thread inactif pour une CPU. Les threads inactifs ne sont exécutés sur une CPU que lorsque les files d'attente d'exécution de la CPU sont vides. |
Le champ pr_addr indique l'adresse d'une structure de données privée et du noyau représentant le thread. Alors que la structure de données est privée, le champ pr_addr peut être utilisé en tant que jeton unique pour déterminer la durée de vie d'un thread.
Le champ pr_wchan est défini lorsque le thread est en sommeil sur un objet de synchronisation. La signification du champ pr_wchan est spécifique à la mise en œuvre du noyau, mais le champ peut être utilisé en tant que jeton unique pour l'objet de synchronisation.
Le champ pr_stype est défini lorsque le thread est en sommeil sur un objet de synchronisation. Les valeurs possibles du champ pr_stype sont indiquées dans le Tableau 25–4.
Tableau 25–4 Valeurs de pr_stype|
SOBJ_MUTEX |
Objet de synchronisation mutex du noyau. Utilisé pour sérialiser l'accès aux zones de données partagées du noyau. Pour plus d'informations sur les objets de synchronisation mutex du noyau, reportez-vous au Chapitre18Fournisseur lockstat et à la page Web mutex_init(9F). |
|
SOBJ_RWLOCK |
Objet de synchronisation de lecture/écriture du noyau. Utilisé pour synchroniser l'accès aux objets partagés du noyau pouvant autoriser plusieurs lecteurs simultanés ou un seul rédacteur. Pour plus d'informations sur les objets de synchronisation de lecture/écriture du noyau, reportez-vous au Chapitre18Fournisseur lockstat et à la page Web rwlock(9F). |
|
SOBJ_CV |
Objet de synchronisation de variable de condition. Une variable de condition est conçue pour attendre indéfiniment jusqu'à ce qu'une condition soit vraie. Les variables de condition sont généralement utilisées pour synchroniser pour des raisons autres que l'accès à une zone de données partagées, et constituent le mécanisme généralement utilisé lorsqu'un processus attend indéfiniment un programme. Par exemple, un blocage dans poll(2), pause(2), wait(3C) et similaire. |
|
SOBJ_SEMA |
Objet de synchronisation de sémaphore. Objet de synchronisation universel qui, comme des objets de variable de condition, ne suit pas la notion de propriété. La propriété étant nécessaire pour mettre en œuvre l'héritage de la priorité dans le noyau Solaris, l'absence de propriété inhérente aux objets de sémaphore empêche leur totale utilisation. Pour plus d'informations, reportez-vous à la page Web semaphore(9F). |
|
SOBJ_USER |
Objet de synchronisation au niveau utilisateur. Tout blocage d'objets de synchronisation au niveau utilisateur est géré avec des objets de synchronisation SOBJ_USER. Les objets de synchronisation au niveau utilisateur incluent ceux créés avec mutex_init(3C), sema_init(3C), rwlock_init(3C), cond_init(3C) et leurs équivalents POSIX. |
|
SOBJ_USER_PI |
Objet de synchronisation au niveau utilisateur mettant en œuvre l'héritage de la priorité. Certains objets de synchronisation au niveau utilisateur suivant la propriété autorisent en outre l'héritage de la priorité. Par exemple, des objets mutex créés avec pthread_mutex_init(3C) peuvent servir à hériter la priorité via pthread_mutexattr_setprotocol(3C). |
|
SOBJ_SHUTTLE |
Objet de synchronisation d'accélération. Les objets d'accélération sont utilisés pour mettre en œuvre des portes. Pour plus d'informations, voir door_create(3DOOR). |
Le champ pr_state est défini sur l'une des valeurs indiquées dans le Tableau 25–5. Le champ pr_sname est défini sur un caractère correspondant indiqué entre parenthèses dans le même tableau.
Tableau 25–5 Valeurs de pr_state|
SSLEEP (S) |
Le thread est au repos. La sonde sched:::sleep se déclenche immédiatement avant la transition de l'état d'un thread en SSLEEP. |
|
SRUN (R) |
Le thread peut être exécuté, mais ne l'est pas actuellement. La sonde sched:::enqueue se déclenche immédiatement avant la transition de l'état d'un thread en SRUN. |
|
SZOMB (Z) |
Le thread est un LWP zombie. |
|
SSTOP (T) |
Le thread est arrêté, en raison d'une directive proc(4) explicite ou d'un autre mécanisme d'arrêt. |
|
SIDL (I) |
Le thread se trouve dans un état intermédiaire lors de la création du processus. |
|
SONPROC (O) |
Le thread est exécuté sur une CPU. La sonde sched:::on-cpu se déclenche dans le cadre du thread SONPROC sur une courte durée après la transition de l'état du thread en SONPROC. |
psinfo_t
Plusieurs sondes proc comprennent un argument du type psinfo_t, structure abordée dans proc(4). La définition de la structure psinfo_t, telle qu'accessible aux clients DTrace, est la suivante :
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;
Le champ pr_dmodel est défini sur PR_MODEL_ILP32, représentant un processus 32 bits ou sur PR_MODEL_LP64, représentant un processus 64 bits.
Exemples
exec
Vous pouvez utiliser la sonde exec pour déterminer facilement les programmes en cours d'exécution et leurs auteurs, tel qu'illustré dans l'exemple suivant :
#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", @);
}
L'exécution de l'exemple de script sur une courte période sur une machine intégrée entraîne une sortie similaire à l'exemple suivant :
# 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 |
start et exit
Pour connaître la durée d'exécution de programmes de la création à la fin, vous pouvez activer les sondes start et exit, tel qu'illustré dans l'exemple suivant :
proc:::start
{
self->start = timestamp;
}
proc:::exit
/self->start/
{
@[execname] = quantize(timestamp - self->start);
self->start = 0;
}
L'exécution de l'exemple de script sur le serveur intégré pendant plusieurs secondes entraîne une sortie similaire à l'exemple suivant :
# 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
|
lwp-start et lwp-exit
Plutôt que de connaître la durée d'exécution d'un processus particulier, vous pouvez souhaiter connaître la durée d'exécution de chaque thread. L'exemple suivant illustre l'utilisation des sondes lwp-start et lwp-exit dans ce but :
proc:::lwp-start
/tid != 1/
{
self->start = timestamp;
}
proc:::lwp-exit
/self->start/
{
@[execname] = quantize(timestamp - self->start);
self->start = 0;
}
L'exécution de l'exemple de script sur un serveur NFS ou de calendriers entraîne une sortie similaire à l'exemple suivant :
# 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
|
signal-send
Vous pouvez utiliser la sonde signal-send pour déterminer le processus d'envoi et de réception associé à chaque signal, tel qu'illustré dans l'exemple suivant :
#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", @);
}
Exécuter ce script engendre une sortie identique à l'exemple suivant :
# 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
|
Stabilité
Le fournisseur proc utilise un mécanisme de stabilité DTrace pour décrire ses stabilités, comme illustré dans le tableau suivant. Pour plus d'informations sur le mécanisme de stabilité, reportez-vous au Chapitre39Stabilité.
|
Élément |
Stabilité des noms |
Stabilité des données |
Classe de dépendance |
|---|---|---|---|
|
Fournisseur |
En cours d'évolution |
En cours d'évolution |
ISA |
|
Module |
Privé |
Privé |
Inconnu |
|
Fonction |
Privé |
Privé |
Inconnu |
|
Nom |
En cours d'évolution |
En cours d'évolution |
ISA |
|
Arguments |
En cours d'évolution |
En cours d'évolution |
ISA |
- © 2010, Oracle Corporation and/or its affiliates