El 06/07/11 16:42, ZorroPlateado escribió: > On Miércoles, 6 de Julio de 2011 08:59:36 Juan Antonio escribió: >> El 06/07/11 00:14, ZorroPlateado escribió: >>> On Martes, 5 de Julio de 2011 11:41:26 usted escribió: >>>> Tengo en Debian una instalación de Alfresco, el caso es que tengo un >>>> script para backups ejecutado desde cron, este script de backup para >>>> Mysql y Alfresco y luego copia sus archivos, posteriormente inicia los >>>> dos servicios. >>>> >>>> El caso es que el orden de los scripts bash ejecutados es el siguiente: >>>> >>>> /etc/init.d/alfresco start >>>> >>>> ===> /mnt/almacen/alfresco/alfresco.sh start >>>> >>>> ===> >>>> /mnt/almacen/alfresco/tomcat/bin/catalina.sh >>>> >>>> Pues bien el script backup usar /etc/init.d/alfresco/ start|stop . Y en >>>> alfresco.sh encontramos un `nohup catalina.sh`. >>>> >>>> El script de backup se ejecuta entero y alfresco es inciado sin >>>> problemas, recibo el email del cron con toda la ejecución. El problema >>>> está en que el proceso de backup aparece como defunct ya que es padre >>>> del proceso java de alfresco que hasta que no termine no cierra el >>>> proceso de backup. >>>> >>>> He lido que el proceso defunc no consume recursos y solo existe mientras >>>> el proceso hijo no termine, con lo cual no deberia de ser ningun >>>> problema. >>>> >>>> Pero pregunto, ¿se puede hacer que en la llamada al script catalina.sh >>>> su proceso padre sea por ejemplo init y de este modo el backup termine? >>> >>> Me he puesto a revisar el contenido del script catalina.sh que acompaña a >>> alfresco y veo que lanza el proceso java con sus parametros haciendo uso >>> de "exec" con lo que ello implica segun el manual de bash.... >>> >>> Por cierto el proceso defunct es el script inicial llamado desde cron, >>> aqui una lista del estado de procesos: >>> >>> root 2872 1 0 21:08 ? 00:00:00 /bin/sh /usr/bin/soffice >>> - accept=socket,host=localhost,port=8100;urp;StarOffic >>> >>> root 2923 1 1 21:08 ? 00:01:14 /usr/lib/jvm/java-1.5.0- >>> sun/jre//bin/java -Djava.util.logging.manager=org.apac >>> >>> root 2949 2872 0 21:08 ? 00:00:00 >>> /usr/lib/openoffice/program/soffice.bin >>> -accept=socket,host=localhost,port=810 >>> >>> root 19222 1 0 May01 ? 00:00:08 /usr/sbin/cron >>> >>> root 20110 2 0 02:05 ? 00:00:03 [pdflush] >>> >>> root 32583 19222 0 20:24 ? 00:00:00 /USR/SBIN/CRON >>> root 32584 32583 0 20:24 ? 00:00:00 [backup-diferenc] >>> <defunct> 104 32587 32583 0 20:24 ? 00:00:00 >>> /usr/sbin/sendmail -i - FCronDaemon -oem root >>> root 32719 2 0 20:24 ? 00:00:07 [pdflush] >> >> Hola, >> >> si ejecutas la tarea a mano, igual que la lanza cron ¿Se queda en el >> mismo estado? Prueba a lanzarla con sh -x y si la salida no es demasiado >> extensa envíala en un correo. >> >> Estando el proceso zombie, prueba a enviarle un SIGHUP a cron, a ver que >> hace. >> >> Un saludo. > > Al ejecutar la tarea a mano no hay problemas con la parada/inicio. Vamos que > todo la parrafada viene desde cron. > > He enviado señal al proceso zombie, que están en estado Zs, es decir el > script > de backup, y no admite ningun kill, solo termina tras finalizar el proceso > alfresco. > > > La situacion de los procesos en cuestion tras ejecutar parada/inicio es ( en > este caso he creado un script que solo realice la parada/inicio de alfresco > llamado > inicio-parada-alfresco.sh que aparece como defunct): > > root 19222 0.0 0.0 3564 988 ? Ss May01 0:08 > /usr/sbin/cron > root 18899 0.0 0.0 3908 944 ? S 16:29 0:00 \_ > /USR/SBIN/CRON > root 18900 0.0 0.0 0 0 ? Zs 16:29 0:00 \_ > [inicio-parada-a] <defunct> > 104 18913 0.0 0.0 6124 1580 ? S 16:29 0:00 \_ > /usr/sbin/sendmail -i -FCronDaemon -oem root > root 18914 168 13.4 1393024 278916 ? Sl 16:29 2:27 > /usr/lib/jvm/java-1.5.0-sun//bin/java -Xms512m -Xmx1024m -server > -XX:CompileCommand=exclude,org/apache/lucene/index/IndexReader$1,doBody > -XX:CompileCommand=exclude,org/alfresco/repo/search/impl/lucene/index/IndexInfo$Merger,mergeIndexes > > -XX:CompileCommand=exclude,org/alfresco/repo/search/impl/lucene/index/IndexInfo$Merger,mergeDeletions > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Djava.util.logging.config.file=/mnt/almacen/alfresco/tomcat/conf/logging.properties > -Djava.endorsed.dirs=/mnt/almacen/alfresco/tomcat/common/endorsed -classpath > :/mnt/almacen/alfresco/tomcat/bin/bootstrap.jar:/mnt/almacen/alfresco/tomcat/bin/commons-logging-api.jar > -Dcatalina.base=/mnt/almacen/alfresco/tomcat > -Dcatalina.home=/mnt/almacen/alfresco/tomcat > -Djava.io.tmpdir=/mnt/almacen/alfresco/tomcat/temp > org.apache.catalina.startup.Bootstrap start > root 18916 0.0 0.0 3992 1236 ? S 16:29 0:00 /bin/sh > /usr/bin/soffice > -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -nologo > -headless -nofirststartwizard > root 18936 0.3 1.1 128440 23700 ? Sl 16:29 0:00 \_ > /usr/lib/openoffice/program/soffice.bin > -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -nologo > -headless -nofirststartwizard > > > > > > > >
Hola, es normal que el proceso defunct no haga nada con las señales, nunca se ejecuta y por lo tanto no las captura. Te decía que le enviases un -HUP al proceso padre, cron en este caso, muchos programas capturan esta señal y hacen una especie de reinicio de todo el contexto del programa, releen la configuración, etc ... y quiza asi se liberen los procesos hijos, aunque el manejador por defecto es enviar un HUP a sus hijos y terminar limpiamente. No es una solución pero si enviando esta señal a mano se liberase puedes añadirlo al final de tu script, ps -e -ostat,ppid,pid,cmd | awk '/^Z/ {print $2}' | xargs kill -HUP y si no funcionara reiniciar el servicio de cron. Es solo una maña y el problema en si no se arregla pero es mejor que nada. Un saludo. -- "Tanto en los deportes como en todo lo demás, soy un experto. Pero para mantener viva mi inteligencia natural y fuera de serie, tengo que comer mucho" -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e15719f.5010...@limbo.ari.es