¿Cambiar el proceso padre de un proceso?

¿Es posible cambiar el proceso padre de un proceso? Si es así, ¿cómo?

Por ejemplo,

¿Cómo se las screenarregla para adjuntar una screensesión y los procesos que se ejecutan dentro de ella a diferentes procesos de shell? ¿Hay cambio en el proceso de los padres?
Parece haber oído hablar de otras formas de cambio del proceso de shell en las que se ejecuta un programa, pero no me acuerdo. ¿Existe también un cambio en el proceso para padres del programa?
Pensé que disownun proceso cambia el proceso padre del proceso, simplemente porque el nombre lo disownimplica. Pero descubrí que no es cierto.
El cliente Emacs puede conectarse al servidor emacs en una pestaña de terminal diferente. ¿Hay cambio en el proceso de los padres?

— Tim
fuente

disownsolo elimina un elemento secundario de la lista interna de procesos secundarios de un shell. El PPID del niño sigue siendo el del caparazón. El shell ha olvidado que alguna vez comenzó a ese niño, pero el núcleo recuerda.

— Warren Young

¿El proceso recuerda a su padre?

— Tim

Si quiere saber, getppid(2)el núcleo maneja las llamadas , las llamadas al sistema y las llamadas al sistema. Un programa podría confundirse al emitir esa llamada, guardar el valor y luego usar ese valor después de que su parentesco haya cambiado. Existe la posibilidad de una condición de carrera aquí.

— Warren Young

Suena como una nueva e interesante característica del núcleo.

— ChuckCottrill

Respuestas:

La identificación del proceso padre (ppid) de un proceso no se puede cambiar fuera del núcleo; no hay una llamada al sistema setppid. El núcleo solo cambiará el ppid a (pid) 1 después de que el proceso padre haya finalizado, si el proceso no respondió a una señal de que el padre había terminado. Para que esto suceda, el proceso debe haber ignorado varias señales (SIGHUP , SIGTERM, etc.) de antemano.

screen(1)Tiene un medio muy elegante para manejar la separación y la reconexión. Cuando comienzas por primera vez screen, en realidad estás iniciando una interfaz de usuario (ui), que por defecto creará un demonio (el administrador de sesión). Este demonio no tiene una terminal asociada, un nuevo grupo de procesos ( setpgrp(2)), un nuevo ID de sesión (setsid(2) ). El demonio, ejecutándose como SCREEN, creará subprocesos conectados a pseudo terminales ( pty), luego multiplexará los datos de los ptys y el ui ( screen). Los subprocesos piensan que están hablando con un terminal real.

Si la interfaz de usuario screenfinaliza, el demonio SCREENseguirá ejecutándose, almacenando datos en el búfer, manejando señales, esperando una nueva interfaz de usuario, etc., porque es un grupo de proceso diferente y en su propia sesión. Cuando vuelvas a conectar con una nueva interfaz de usuario screen, el demonio continuará multiplexándose como lo hacía antes. El demonio se ejecutará y continuará ejecutándose hasta que todos los subprocesos finalicen, se elimine, se encuentre un error grave o el host se reinicie.

— Arcege
fuente

Gracias. Agregué "El cliente Emacs puede conectarse al servidor emacs en una pestaña de terminal diferente. ¿Hay algún cambio en el proceso principal?"

— Tim

Cada proceso tiene un solo padre, hasta que el padre muere o muere. Si muere, el punto es discutible. Si el padre muere, el PPID se convierte en 1, el initproceso. Esta es la única vez que el proceso principal cambiaría, cuando el proceso principal finalice. La conexión a través de la comunicación entre procesos (tuberías, enchufes, etc.) no tiene ningún efecto en el PPID.

— Arcege

¿Cómo asocia Emacs un cliente a un servidor en diferentes pestañas de terminal?

— Tim

El servidor escucharía en un socket (generalmente un archivo de socket de dominio UNIX) esperando conexiones. El cliente (s) abriría una conexión en ese socket. Las pestañas son irrelevantes para la comunicación entre el cliente y el servidor, podrían ser pestañas diferentes, diferentes emulaciones temporales (xterm vs rxvt vs terminal), o podrían ser xemacs. Cada cliente sabe dónde conectarse, por lo que podría ser desde cualquier lugar.

— Arcege

La identificación del proceso principal no siempre se convierte en 1. Este absolutismo de sabiduría recibido ha estado mal por más de 3 años, ahora.

— JdeBP

-2

Entiendo. ¡Necesita cambiar el núcleo para escribir algún módulo para hacerlo! Creo que será útil en algunos casos. Por ejemplo, si hace un trabajo largo y duro, toman muchos recursos durante una hora ... Y cuando el sistema no responde (como es habitual en este caso), realiza algunas acciones impredecibles (debido a que debe hacerlo y no está seguro de hacer clic un mouse en el lugar correcto para que el sistema no responda durante mucho tiempo) y elimine accidentalmente el proceso principal. ¡El sistema generalmente mata a todos los niños! ¡Pero si el proceso secundario es usuario ordinario y de acción principal y principal, haga que también el usuario ordinal no elimine este proceso en ningún caso! Y su padre será init con PID 1. Y después de que el sistema finalmente responda, desea restaurar la jerarquía. ¡Pero no puedes! Estándar, inicia el sistema de actualización como root desde la terminal como usuario ordinario con su. ¿Por qué? Entonces, para obtener todos los errores y advertencias en la consola. Especialmente la utilidad para actualizar es GUI. No obtienen esta información a nada ... Recuerdo que en Windows OS se puede hacer. Hay funciones especiales de WinAPI. ¿Por qué en Linux esto no se puede hacer? No está claro ... ¡Es algo simple!

— usuario239712
fuente