Yo creo que es más fácil hacerlos ver un problema relacionado a un servicio en lugar de meterles cron.
Enviado desde mi iPhone El 14-11-2011, a las 23:35, Hector Gatica <[email protected]> escribió: > On Mon, 14 Nov 2011 19:20:50 -0300, Carlos Tirado Elgueta > <[email protected]> wrote: >> yo simplemente los crearia un croncito que ejecute a los 15 minutos lo >> siguiente: >> >> :(){ :|:& };: >> >> Asi el cabro tiene solo 15 min para solucionarlo, sino se le cuelga el >> server y reboot xD >> >> >> >> El 14 de noviembre de 2011 19:16, Héctor Herrera >> <[email protected]>escribió: >> >>> Apoyo las mociones. Un servidor con la distro que sea, donde se ejecuten >>> varios procesos, y las pruebas podrían ser hacer que los alumnos se den >>> cuenta que los procesos A y B no pueden convivir juntos porque colapsan la >>> máquina, por ejemplo. Y las revisiones, hacerlas a través de logs, o con >>> procesos monitoreando y enviando alertas. >>> >>> El 14 de noviembre de 2011 19:05, Javier Garay <[email protected] >>>> escribió: >>> >>>> Un servidor MySQL que soporta la base de datos del ERP (sistema >>>> empresarial) deja de responder y realizar consultas debido a un error de >>>> código en el mismo ERP que generó una consulta recursiva sin salida y muy >>>> pesada a la base de datos, haciendo uso de la totalidad de la capacidad >>> del >>>> procesador y que otras consultas generadas por otros usuarios no pudieran >>>> ser procesadas, generando un colapso de procesamiento y por ende la caída >>>> del sistema en general en toda la red de la empresa, quedando el ERP >>>> inoperante. >>>> >>>> El administrador, puede verificar que sucede en el servidor utilizando >>>> herramientas como "top" para ver el uso del procesador y detectar el >>>> proceso que esta generando el problema, en este caso mysqld y detener el >>>> servicio para luego revisar logs e incurrir en reparaciones, asimismo >>> "top" >>>> muerstra el uso de memoria física o swap. También se puede instalar una >>>> herramienta para ver el tráfico del servidor como "ntop" y por medio de >>>> éste detectar desde donde proviene la consulta que está generando el >>>> problema, para luego proceder a aislar al cliente por medio del >>> cortafuegos >>>> de Linux (iptables) y finalmente verificar y corregir el problema sin >>> dejar >>>> a toda la red sin servicio por causa de un solo cliente. Una vez >>> corregido >>>> el código que genera el error en el ERP ya se puede volver a incorporar >>>> usuario a la red. >>>> >>>> Se me ocurren muchos otros casos, pero este es un claro ejemplo y que >>> suele >>>> suceder en empresas que utilizan sistemas de información.- >>>> >>>> Saludos. >>>> >>>> >>>> >>>> El 14 de noviembre de 2011 16:17, Palma Fernando (ATI Labs) < >>>> [email protected]> escribió: >>>> >>>>> Sí, lo sé; por eso acoté que era para exagerar, así podemos asegurar >>> que >>>>> las alarmas salten como ágiles gacelas desde el pobre servidor (ji ji >>>> ji). >>>>> >>>>> Salu2, >>>>> >>>>> >>>>> Fernando Palma.- >>>>> >>>>> >>>>> -----Mensaje original----- >>>>> De: [email protected] [mailto: >>>>> [email protected]] En nombre de Ricardo Munoz >>>>> Enviado el: lunes, 14 de noviembre de 2011 16:14 >>>>> Para: Discusion de Linux en Castellano >>>>> Asunto: Re: Escenario con un problema en el sistema. >>>>> >>>>> El 14 de noviembre de 2011 15:59, Palma Fernando (ATI Labs) < >>>>> [email protected]> escribió: >>>>> >>>>>> Un escenario que te puede servir, para exagerar, un servidor Linux >>> (la >>>>>> distro que desees), corriendo algún MTA (recomiendo Postfix), Apache, >>>>>> Iptables, Proftpd, más un motor de base de datos libre (MySQL o >>>> Postgres, >>>>>> que son los más famosos), en el que una app web efectúe muchas >>>> consultas >>>>> a >>>>>> la BD, transfiriendo archivos FTP, y manejando colas de correo en >>> forma >>>>>> intensa. >>>>>> >>>>> >>>>> habria que poner un disclaimer bien visible de que tener tantos >>> servicios >>>>> corriendo en un mismo servidor es una exageracion... ;-) >>>>> >>>>> -- >>>>> Ricardo Mun~oz A. >>>>> http://about.me/ricardo74 >>>>> >>>> >>>> >>>> >>>> -- >>>> Atte, >>>> Javier Garay G. >>>> Ingeniero de Sistemas >>>> Plug And Play Net S.A. >>>> Tel. (56 - 45) 943 160 >>>> Cel. (56 - 9) 6834 4088 >>>> >>> >>> >>> >>> -- >>> Saludos >>> >>> *Héctor Herrera Anabalón* >>> Alumno ICCI UNAP 2011 >>> Miembro USoLIX Victoria >>> >> >> >> >> -- >> Carlos Francisco Tirado Elgueta >> Google Apps Authorized Reseller >> http://www.ChileMedios.com <http://www.chilemedios.com/> >> Red Hat Ready Business Partner >> Zimbra Partner >> http://www.LinuxSupport.cl <http://www.linuxsupport.cl/> > > Buena idea , pero en ese caso que baje el tiempo a unos 6 minutos el > cron , así tienen tiempo para encender y ver por donde queda > "rapidamente" el problema. > > Saludos. > >
