7 votos

El programador de tareas sólo mata a cmd.exe pero no a sus procesos hijos

Nuestro cliente tiene algunos servidores Windows 2003 que ejecutan trabajos por lotes activados por el Programador de Tareas. Los programas que realizan el trabajo son procesos .exe personalizados, y están agrupados en .cmd scripts para que sean lanzados juntos por el Programador de Tareas cuando llegue el intervalo programado. Las líneas dentro del cmd scripts pueden o no utilizar el comando Call para lanzar los programas .exe separados.

En esta configuración, el Programador de Tareas está supervisando efectivamente cmd.exe, y cuando se utiliza el Explorador de Procesos, se puede observar que los procesos .exe hijos están aparcados bajo el árbol de procesos de cmd.exe. Sin embargo, cuando el Programador de Tareas mata a cmd.exe por exceder el límite de tiempo permitido, los procesos .exe hijos no se matan junto con su padre y quedan huérfanos. Estos procesos permanecen estancados indefinidamente. Debido al estado de los hilos de proceso mostrados en el Explorador de Procesos, sospecho que esos procesos terminan en error y aparece un cuadro de diálogo del depurador .NET (son aplicaciones .NET) que no se puede ver ya que el usuario del trabajo por lotes es una cuenta de usuario independiente.

Inicialmente, cuando estaba investigando este comportamiento en mi estación de trabajo de Windows XP, observé que los procesos .exe hijos que se lanzan desde mi script de prueba son eliminados junto con el cmd.exe cuando el Programador de Tareas decide que el tiempo ha terminado. No había forma de dejar huérfanos a los procesos hijos.

Basado en una corazonada, finalmente me trasladé a una máquina Windows 2003 para probar esto. Del mismo modo, los procesos hijos se terminan como los de mi estación de trabajo. Mi segundo paso fue entonces utilizar otra cuenta de usuario para ejecutar la tarea programada. Esta vez, cmd.exe es eliminado después de exceder el límite de tiempo, pero los procesos hijos permanecen en pie, al igual que lo que mi cliente observó en sus servidores de producción.

Si inicio la sesión de forma preventiva en esa cuenta de usuario por lotes (que resulta ser otra cuenta de administrador) para reclamar una sesión de escritorio, cualquier error o información emergente de mis programas .exe de prueba se dirigiría y se mostraría en ese escritorio, permitiéndome ver la salida real del usuario. Si sólo me conecto después de que la tarea programada haya sido invocada, la sesión de escritorio no "reclamará" las ventanas de los procesos existentes; éstas permanecerán ocultas para siempre.

Mi pregunta es, ¿qué condición(es) me falta(n) aquí que puede(n) causar que el Programador de Tareas no borre los procesos hijos bajo un cmd.exe? ¿Qué hay de especial en el uso de otra cuenta que podría inducir este comportamiento, pero no cuando se utiliza mi cuenta de administrador actual para ejecutar la tarea programada?

2voto

Warren Stevens Puntos 131

Pruebe a utilizar "Taskkill /T" en la línea de comandos. (/T = " Termina el proceso especificado y cualquier proceso hijo que haya sido iniciado por él ")

Si tiene varios procesos en ejecución (a menudo tenemos 5 o más "powershell.exe" en ejecución), añada la columna "Línea de comandos" a la pestaña "Detalles" del Administrador de tareas. Eso debería dejar claro qué ID de proceso es el que quieres eliminar

1voto

JCCyC Puntos 328

Los procesos son independientes en Windows - Matar un proceso padre no terminará automáticamente un proceso hijo.

0voto

Adam Brand Puntos 4827

Si crees que se debe a la aparición de un mensaje del depurador, ¿has probado a envolver el código en un try{}catch{} y registrando el error?

De lo contrario, tal vez lo que podrías hacer es que los procesos escriban la salida de WindowsPrincipal wp = new WindowsPrincipal(WindowsIdentity.GetCurrent())

Sospecho que los niños, de alguna manera, están escalando su nivel de privilegio a Administrador y entonces no pueden ser asesinados con el padre.

Para probar esto sin modificar el código, puedes escribir otra tarea programada que intente matar los otros procesos usando taskkill . Esta tarea programada debe ejecutarse como administrador. Si eso funciona, entonces parece que es un problema de seguridad.

0voto

Bork Blatt Puntos 415

¿Qué tal si utilizamos el pskill que forma parte de la suite SysInternals. Este programa puede matar procesos por nombre. Yo añadiría una tarea programada, que se ejecutará unos minutos después de que espere que los procesos hayan terminado, que ejecutará pskill para terminarlos.

PSKill también puede ejecutarse con las credenciales de usuario que usted proporcione en la línea de comandos.

0voto

onit Puntos 166

No sé si esto solucionará tu problema, pero si está relacionado con las cajas emergentes (y puede que lo esté - la aplicación está en estado de fallo, y suspendida mientras el usuario inexistente decide qué hacer al respecto).

Echa un vistazo a http://blogs.msdn.com/shawnfa/archive/2004/07/15/184490.aspx y ver si puedes deshacerte de esas cajas...

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: