Escenario con un problema en el sistema.

[Javier Garay]

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
<hector.gatica en opensynapse.cl> escribió:

> On Mon, 14 Nov 2011 19:20:50 -0300, Carlos Tirado Elgueta
> <carlos.tirado en gmail.com> 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
>> <hherreraa en gmail.com>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 <javierzgaray en gmail.com
>>>> 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) <
>>>> fpalma en ati-labs.com> 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: linux-bounces en listas.inf.utfsm.cl [mailto:
>>>>> linux-bounces en listas.inf.utfsm.cl] 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) <
>>>>> fpalma en ati-labs.com> 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.
>
>