Por fin luego de tanto batallar ya dimos con el resultado de este asunto que muchos lectores de nuestra web han tenido. Si deseas compartir alguna información no dejes de dejar tu información.
Solución:
En Linux, cada proceso tiene varias ID asociadas, que incluyen:
-
ID de proceso (PID)
Este es un número arbitrario que identifica el proceso. Cada proceso tiene una identificación única, pero después de que el proceso sale y el proceso principal ha recuperado el estado de salida, la identificación del proceso se libera para que la reutilice un nuevo proceso.
-
ID de proceso principal (PPID)
Este es solo el PID del proceso que inició el proceso en cuestión. Si el proceso padre sale antes que el hijo, el PPID del hijo se cambia a otro proceso (generalmente PID 1).
-
ID de grupo de proceso (PGID)
Este es solo el PID del líder del grupo de procesos. Si PID == PGID, entonces este proceso es un líder de grupo de procesos.
-
ID de sesión (SID)
Este es solo el PID del líder de la sesión. Si PID == SID, entonces este proceso es un líder de sesión.
Las sesiones y los grupos de procesos son solo formas de tratar una serie de procesos relacionados como una unidad. Todos los miembros de un grupo de procesos siempre pertenecen a la misma sesión, pero una sesión puede tener varios grupos de procesos.
Normalmente, un shell será un líder de sesión y cada tubería ejecutada por ese shell será un grupo de procesos. Esto es para que sea más fácil matar a los hijos de un caparazón cuando sale. (Vea la salida (3) para los detalles sangrientos).
No creo que haya un término especial para un miembro de una sesión o grupo de proceso que no sea el líder.
Un líder de sesión es un proceso donde id de sesión == id de proceso. Esto suena artificial, pero la identificación de la sesión la heredan los procesos secundarios. Algunas operaciones dentro de UNIX/Linux operan en sesiones de proceso, por ejemplo, negando la identificación del proceso cuando se envía a la llamada o comando de matar al sistema. El uso más común para esto es cuando se cierra sesión en un shell. El sistema operativo enviará kill -HUP -$$, que enviará una señal SIGHUP (colgar) a todos los procesos con la misma identificación de sesión que el shell. Cuando rechaza un proceso, la identificación de la sesión del proceso se cambia desde el shell, por lo que no responderá a la señal de colgar. Esta es una parte del proceso para convertirse en un proceso daemon.
La mayoría de los procesos llamados desde el administrador de ventanas/entorno gráfico tienen la misma identificación de sesión que uno de los programas de inicio. Esto permite que el sistema operativo realice el mismo kill -HUP -$$ operación en todos los programas: como su navegador, reproductor de música, libreoffice, cliente de mensajería instantánea, etc. Estos son los procesos que no son líderes de sesión.
Pensé que sabía la respuesta a esto, pero escribí un programa en C para resolverlo.
#include
#include
int
main(int ac, char **av)
pid_t sid, mypid, pgid, gid;
mypid = getpid();
sid = getsid(0);
pgid = getpgid(0);
gid = getpgrp();
printf("PID %dn", mypid);
printf("process group ID of session leader: %dn", sid);
printf("process group ID: %dn", pgid);
printf("process group ID: %dn", gid);
if (!fork())
mypid = getpid();
sid = getsid(0);
pgid = getpgid(0);
gid = getpgrp();
printf("child PID %dn", mypid);
printf("process group ID of session leader: %dn", sid);
printf("process group ID: %dn", pgid);
printf("process group ID: %dn", gid);
_exit(0);
return 0;
lo compilé con cc -g -o sid sid.c Lo ejecuté de diferentes maneras, para ver qué sucede:
./sid
nohup ./sid > sid.out
setsid ./sid
Me sorprendió un poco lo que Linux (2.6.39) devolvió. También encontré la página del manual de la sección 7, “credenciales”.
mi consejo es hacer man 7 credentials (o el equivalente si no está en Linux), y lea la sección sobre el grupo de procesos y la sesión para ver si puede descifrarlo.