Capítulo 25 Proveedorproc
El proveedor proc pone a su disposición sondeos relativos a las siguientes actividades: creación y finalización de procesos, creación y finalización de LWP, ejecución de imágenes de nuevos programas y envío y manejo de señales.
Sondeos
Los sondeos proc se describen en la Tabla 25–1.
Tabla 25–1 Sondeos proc|
Sondeo |
Descripción |
|---|---|
|
create |
Sondeo que se activa siempre que se crea un proceso mediante fork(2), forkall(2), fork1(2) o vfork(2). El psinfo_t correspondiente al nuevo proceso subordinado es apuntado por args[0]. Es posible distinguir vfork del resto de variantes de bifurcación para PR_VFORKP en el miembro pr_flag del lwpsinfo_t del subproceso que se bifurca. Puede distinguir fork1 de forkall examinando los miembros pr_nlwp del psinfo_t del proceso principal ( curpsinfo) y del proceso subordinado psinfo_t ( args[0]). Dado que el sondeo create sólo se activa después de crear correctamente el proceso, y ya que la creación de LWP forma parte de un proceso de creación, lwp-create se activará para cualquier LWP creado en el momento de creación del proceso antes de que se active el sondeo create para el nuevo proceso. |
|
exec |
Sondeo que se activa siempre que un proceso carga una nueva imagen de proceso con una variante de la llamada de sistema exec(2): exec(2), execle(2), execlp(2), execv(2), execve(2), execvp(2). El sondeo exec se activa antes de que se cargue la imagen del proceso. Por lo tanto, las variables de proceso como execname y curpsinfo contienen el estado del proceso antes de cargar la imagen. Poco tiempo después de activarse el sondeo exec, se activará en el mismo subproceso el sondeo exec-failure o el sondeo exec-success. La ruta de la imagen del nuevo proceso es apuntada por args[0]. |
|
exec-failure |
Sondeo que se activa siempre que falla una variante exec(2). El sondeo exec-failure sólo se activa después de que se active el sondeo exec en el mismo subproceso. El valor errno(3C) se proporciona en args[0] . |
|
exec-success |
Sondeo que se activa siempre que se realiza correctamente una variante exec(2). Al igual que el sondeo exec-failure, el sondeo exec-success sólo se activará después de que se active el sondeo exec en el mismo subproceso. En el momento en el que se activa el sondeo exec-success, variables de proceso execname y curpsinfo contienen el estado del proceso después de que se haya cargado la imagen del nuevo proceso. |
|
exit |
Sondeo que se activa cuando el proceso actual se está cerrando. La razón del cierre, que se expresara como uno de los códigos SIGCHLD siginfo.h(3HEAD), se encuentra en args[0]. |
|
fault |
Sondeo que se activa siempre que se produce un fallo del sistema en un subproceso. El código de error (tal y como se define en proc(4)) se encuentra en args[0]. La estructura siginfo que corresponde al fallo es apuntado por args[1]. Sólo los fallos que pueden inducir una señal pueden activar el sondeo fault. |
|
lwp-create |
Sondeo que se activa siempre que se crea un LWP, normalmente a raíz de u thr_create(3C). El lwpsinfo_t correspondiente al nuevo subproceso es apuntado por args[0]. El psinfo_t del proceso que contiene el subproceso es apuntado por args[1]. |
|
lwp-start |
Sondeo que se activa en el contexto de un LWP de reciente creación. El sondeo lwp-start se ejecutará antes de que se ejecute cualquier tipo de instrucción a nivel de usuario. Si el LWP es el primer LWP del proceso se activará el sondeo start, seguido de lwp-start. |
|
lwp-exit |
Sondeo que se activa cuando se está cerrando un LWP, debido a una señal o a una llamada explícita a thr_exit(3C). |
|
signal-discard |
Sondeo que se activa cuando se envía una señal a un proceso con un único subproceso y el proceso desbloquea e ignora la señal. Bajo estas condiciones, la señal se descarta tras su generación. El lwpsinfo_t y psinfo_t del proceso y subproceso objetivo se encuentran en args[0] y args[1], respectivamente. El número de señal está en args[2]. |
|
signal-send |
Sondeo que se activa siempre que se envía una señal a un proceso o subproceso. El sondeo signal-send se activa en el contexto del proceso y subproceso que se envía. El lwpsinfo_t y psinfo_t del proceso y subproceso de recepción están en args[0] y args[1], respectivamente. El número de señal está en args[2]. signal-send está siempre seguido de signal-handle o signal-clear en el proceso y subproceso de recepción. |
|
signal-handle |
Sondeo que se activa inmediatamente antes de que un subproceso maneje una señal. El sondeo signal-handle se activa en el contexto del subproceso que manejará la señal. El número de señal está en args[0]. Un puntero a la estructura siginfo_t que se corresponde con la señal está en args[1]. El valor de args[1] es NULL si no hay estructura de siginfo_t o si el controlador de señales carece del conjunto de indicadores SA_SIGINFO. La dirección del manejador de señal del proceso está en args[2]. |
|
signal-clear |
Sondeo que se activa cuando se borra una señal pendiente porque el subproceso de destino estaba esperando la señal en sigwait(2), sigwaitinfo(3RT) o sigtimedwait(3RT). Bajo estas circunstancias, la señal pendiente se borra y se devuelve el número de señal al emisor de la llamada. El número de señal está en args[0]. signal-clear se activa en el contexto del subproceso que anteriormente estaba en estado de espera. |
|
start |
Sondeo que se activa en el contexto de un proceso de reciente creación. El sondeo start se activará antes de que se ejecuten en el proceso instrucciones a nivel de usuario. |
Argumentos
Los tipos de argumento de los sondeos proc se encuentran en la Tabla 25–2. Los argumentos se describen en la Tabla 25–1.
Tabla 25–2 Argumentos del sondeo proc|
Sondeo |
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
Varios sondeos proc cuentan con argumentos del tipo lwpsinfo_t, estructura que se documenta en proc(4). La definición de la estructura lwpsinfo_t, tal y como se pone a disposición de los consumidores DTrace es la siguiente:
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;
El campo pr_flag es un indicador de retención de máscara de bits que describe el proceso. Estos indicadores y su significado se describen en la Tabla 25–3.
Tabla 25–3 Valores pr_flag|
PR_ISSYS |
El proceso es un proceso del sistema. |
|
PR_VFORKP |
El proceso es el proceso principal de un secundario vfork(2)'d. |
|
PR_FORK |
El proceso tiene establecido el modo inherit-on-fork. |
|
PR_RLC |
El proceso tiene establecido el modo run-on-last-close. |
|
PR_KLC |
El proceso tiene establecido el modo kill-on-last-close. |
|
PR_ASYNC |
El proceso tiene establecido el modo asynchronous-stop. |
|
PR_MSACCT |
El proceso tiene habilitado la contabilidad de microestado. |
|
PR_MSFORK |
El registro de microestado del proceso se hereda en la bifurcación. |
|
PR_BPTADJ |
El proceso tiene establecido el modo de ajuste del punto de interrupción. |
|
PR_PTRACE |
El proceso tiene establecido el modo de compatibilidad con ptrace(3C). |
|
PR_STOPPED |
El subproceso es un LWP que se encuentra detenido. |
|
PR_ISTOP |
El subproceso es un LWP detenido en un evento de interés. |
|
PR_DSTOP |
El subproceso es un LWP que tiene efectiva una directiva de detención. |
|
PR_STEP |
El subproceso es un LWP que tiene efectiva una directiva de paso único. |
|
PR_ASLEEP |
El subproceso es un LWP en inactividad no interrumpible dentro de una llamada de sistema. |
|
PR_DETACH |
El subproceso es un LWP desasociado. Consulte pthread_create(3C) y pthread_join(3C). |
|
PR_DAEMON |
El subproceso es un LWP daemon. Consulte pthread_create(3C). |
|
PR_AGENT |
El subproceso es el LWP agente para el proceso. |
|
PR_IDLE |
El subproceso es el subproceso inactivo de una CPU. Los subprocesos inactivos sólo se ejecutan en una CPU cuando las colas de ejecución de la CPU están vacías. |
El campo pr_addr es la dirección de una estructura de datos privada y del núcleo que representa el subproceso. Aunque la estructura de datos es privada, el campo pr_addr podría utilizarse como un símbolo único para un proceso durante el tiempo que dure el subproceso.
El campo pr_wchan está establecido cuando el subproceso se encuentra en inactividad en un objeto de sincronización. El significado del campo pr_wchan es privado para la implementación del núcleo, pero este campo puede utilizarse como un símbolo único para el objeto de sincronización.
El campo pr_stype se establece cuando el subproceso se encuentra inactivo sobre un objeto de sincronización. Los posibles valores del campo pr_stype se encuentran en la Tabla 25–4.
Tabla 25–4 Valores pr_stype|
SOBJ_MUTEX |
Objeto de sincronización de exclusión mutua del núcleo. Se utiliza para serializar el acceso a las regiones de datos compartidos del núcleo. Consulte el Capítulo 18Proveedor lockstat y mutex_init(9F) para obtener más información sobre los objetos de sincronización de exclusión mutua del núcleo. |
|
SOBJ_RWLOCK |
Objeto de sincronización lectores/escritor del núcleo. Se utiliza para sincronizar el acceso a los datos compartidos del núcleo que pueden permitir varias lecturas simultáneas o un único escritor. Consulte el Capítulo 18Proveedor lockstat y rwlock(9F) para obtener detalles acerca de los objetos de sincronización lectores/escritor del núcleo. |
|
SOBJ_CV |
Objeto de sincronización de variable de condición. Las variables de condición están diseñadas para esperar de forma indefinida hasta que alguna condición se convierta en true. Las variables de condición suelen utilizarse para sincronizarse por razones diferentes al acceso a una región de datos compartida, y son el mecanismo que suele usarse cuando un proceso realiza una espera indefinida inducida por un programa. POr ejemplo, bloqueos en poll(2), pause(2), wait(3C), etcétera. |
|
SOBJ_SEMA |
Objeto de sincronización semáforo. Objeto de sincronización de propósito general que – al igual que los objetos de variable de condición– no realiza el seguimiento de una noción de propiedad. Dado que la propiedad es necesaria para implementar la herencia de prioridad en el núcleo de Solaris, la falta de propiedad inherente en objetos de semáforo impide un uso más extenso. Consulte semaphore(9F) para obtener más información. |
|
SOBJ_USER |
Objeto de sincronización a nivel de usuario. Todo el bloqueo en objetos de sincronización a nivel de usuario se maneja con objetos de sincronización SOBJ_USER. Entre los objetos de sincronización de nivel de usuario se incluyen los objetos creados con mutex_init(3C), sema_init(3C), rwlock_init(3C), cond_init(3C) y sus equivalentes POSIX. |
|
SOBJ_USER_PI |
Objeto de sincronización a nivel de usuario que implementa la herencia de prioridad. Determinados objetos de sincronización a nivel de usuario que realizan seguimiento de la prioridad, además permiten realizar un seguimiento de la herencia de la prioridad. Por ejemplo, los objetos de exclusión mutua creados con pthread_mutex_init(3C), es posible que fueran creados con la intención de heredar la prioridad con pthread_mutexattr_setprotocol(3C). |
|
SOBJ_SHUTTLE |
Objeto de sincronización lanzadera. Los objetos lanzadera se utilizan para implementar puertas. Consulte door_create(3DOOR) para obtener más información. |
El campo pr_state se establece en uno de los valores de la Tabla 25–5. El campo pr_sname se define en un carácter correspondiente, mostrado en paréntesis en la misma tabla.
Tabla 25–5 Valores pr_state|
SSLEEP (S) |
El subproceso está inactivo. El sondeo sched:::sleep se activará inmediatamente antes de la transición de estado de un subproceso a SSLEEP. |
|
SRUN (R) |
El subproceso puede ejecutarse, pero no se encuentra actualmente en ejecución. El sondeo sched:::enqueue se activará inmediatamente antes de que el estado de un subproceso realice la transición a SRUN. |
|
SZOMB (Z) |
El subproceso es un LWP zombie. |
|
SSTOP (T) |
El subproceso está detenido, bien a raíz de una directiva proc(4) explícita o de algún otro mecanismo de detención. |
|
SIDL (I) |
El subproceso es un estado intermedio durante la creación del proceso. |
|
SONPROC (O) |
El subproceso está en ejecución en una CPU. El sondeo sched:::on-cpu se activará en el contexto del subproceso SONPROC escaso tiempo después de que el estado del subproceso realice la transición a SONPROC. |
psinfo_t
Varios sondeos proc cuentan con un argumento del tipo psinfo_t, estructura que se documenta en proc(4). La definición de la estructura psinfo_t, tal y como se pone a disposición de los consumidores DTrace es la siguiente:
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;
El campo pr_dmodel se establece en PR_MODEL_ILP32, para indicar un proceso de 32–bits, o en PR_MODEL_LP64, para indicar un proceso de 64–bits.
Ejemplos
exec
Es posible utilizar el sondeo exec para determinar fácilmente qué programas se encuentran en ejecución y quién los ejecuta, tal y como puede ver en el siguiente ejemplo:
#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", @);
}
La ejecución del ejemplo durante un breve periodo de tiempo en un sistema de creación devolverá una salida similar a la del siguiente ejemplo:
# 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 y exit
Si desea saber durante cuánto tiempo los programas se encuentran en ejecución desde su creación hasta su finalización, puede habilitar los sondeos start y exit, tal y como se indica en el siguiente ejemplo:
proc:::start
{
self->start = timestamp;
}
proc:::exit
/self->start/
{
@[execname] = quantize(timestamp - self->start);
self->start = 0;
}
La ejecución de la secuencia de comandos en el servidor de creación durante varios segundos devolverá una salida similar a la del siguiente ejemplo:
# 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 y lwp-exit
En lugar de saber el tiempo que tarda en ejecutarse un proceso determinado, puede que le interese saber cuánto tiempo tarda en ejecutarse un subproceso. El siguiente ejemplo muestra cómo utilizar los sondeos lwp-start y lwp-exit con esta finalidad:
proc:::lwp-start
/tid != 1/
{
self->start = timestamp;
}
proc:::lwp-exit
/self->start/
{
@[execname] = quantize(timestamp - self->start);
self->start = 0;
}
La ejecución de la secuencia de comandos de ejemplo en un servidor NFS y de calendario devuelve una salida similar a la del ejemplo siguiente:
# 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
Puede utilizar el sondeo signal-send para determinar los procesos de envío y recepción asociados a cualquier señal, tal y como se muestra en el siguiente ejemplo:
#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", @);
}
La ejecución de esta secuencia de comandos devuelve una salida similar a la que se muestra en el siguiente ejemplo:
# 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
|
Estabilidad
El proveedor proc utiliza el mecanismo de estabilidad de DTrace para describir sus estabilidades, tal y como se muestra en la tabla siguiente. Para obtener más información sobre el mecanismo de estabilidad, consulte el Capítulo 39Estabilidad.
|
Elemento |
Estabilidad del nombre |
Estabilidad de los datos |
Clase de dependencia |
|---|---|---|---|
|
Proveedor |
Evolutivo |
Evolutivo |
ISA |
|
Módulo |
Privado |
Privado |
Desconocido |
|
Función |
Privado |
Privado |
Desconocido |
|
Nombre |
Evolutivo |
Evolutivo |
ISA |
|
Argumentos |
Evolutivo |
Evolutivo |
ISA |
- © 2010, Oracle Corporation and/or its affiliates