Cronicas de un viaje anunciado: Dia1

La semana pasada realice un viaje que ya les había anunciado previamente en algunas redes sociales, viajar mas de siete horas para llegar a Real de Catorce un viejo pueblo minero en el norte de México, con características muy propias a mi parecer de la época de la revolución mexicana a inicios del siglo XX.

La aventura comenzó la madrugada del sábado 12/02/2011 en la central de autobuses de Morelia, con un retraso considerable del autobus. A pesar de este pequeño inconveniente puede llegar a las 11:30am a Matehuala, lugar donde mi primo Abraham pasaría por mi para llegar juntos al pueblo.

El recorrido Matehuala-Real de Catorce, es poco mas de 40min. sobre todo por que la mitad del recorrido es un camino de piedras. Cuando comenzó el camino de piedra le pedí a mi primo tomarnos unas fotos, aprovechando para estirar un poco las piernas y respirar los aromas del desierto de San Luis Potosí.

Dejaremos al lector una idea mas clara de lo que es el lugar usando las herramientas que google nos ofrece, vamos al google streetmaps para ver el lugar donde nos tomamos algunas fotos.

Ver mapa más grande

Al final del camino de piedra llegamos a la entrada del tunel Ogarrio, el cual nos lleva directamente al pueblo.

Una vez en el pueblo, nos dispusimos a satisfacer primeramente algunas de las necesidades básicas del hombre, comer y un lugar para dormir. En cuanto al hospedaje nos quedamos en Hotel Real de Álamos un lugar para dormir sin muchas comodidades pero bien, un hotel pueblerino de esos que eventualmente se antojan para ir a descasar y olvidarte de la ciudad.
Para la comida, me deleite con el famoso platillo de enchiladas potosinas, siendo aquí el lugar donde las comí por primera vez.
Después de la comida el momento de nuestro primer recorrido había llegado, se decidió democraticamente ir primero al pueblo fantasma de Real de Catorce, este pueblo fue originalmente el que estaba habitado, sin embargo en algún momento de la historia deciden ir mas abajo, la razón no la conozco. Los argumentos ofrecidos por los habitantes y guías son diversos incluso de la información que hay en Internet.
El recorrido es en caballo y hay que subir un cerro con un camino muy empedrado y recientemente mas dañado por las lluvias causadas por el Huracán Alex. A lo largo el camino podemos apreciar construcciones aisladas del pueblo fantasma, la mayoría de ellas destruidas, casas, cuartos de almacenaje de dinamita, edificios, haciendas, etc.

Pudimos conocer por afuera una de las minas con una profundidad de 500mts, se trata de un pozo principal de extracción de minerales de unos nueve metros de diámetro, hay túneles estrechos que los mineros usaban para descender a esa profundad. Supongo que una de tus preguntas es ¿Que minerales se extraían?, de estas minas se extraían varios metales como el mercurio, pero principalmente era plata.
El recorrido duro aproximadamente dos horas. De regreso en el pueblo pasamos a cenar y tomar unas cervezas en un pequeño bar. Ahí nos enteramos que esta vieja mina volverá a operar en los próximos meses, una compañía de Canadá es la que estará a cargo con mano de obra de la región.
Finalmente quiero dejar disponible el álbum de fotos donde subí algunas de ellas. En el próximo post vamos a ver el siguiente día de aventuras.

ulimit & limits.conf: Recursos del sistema

Primeramente quiero aprovechar este espacio para desear feliz año nuevo a mis escasos y desatendidos lectores ya que últimamente (varios meses atrás) que no he colocado nada por aquí. Para ponerme al día, tocaremos este sencillo pero importante tópico.

GNU/Linux nos provee varios mecanismos para administrar los recursos del sistema, como el paso de parámetros al kernel, memoria (scheduling priority), recursos físicos, etc. Los limites PAM ( pam_limits ), son limites de los recursos del sistema que son aplicados a los usuarios al iniciar sesión. Entre algunos de los recursos a los que les podemos aplicar este limite tenemos los siguientes:

• Máximo numero de archivos abiertos.
• Máximo tiempo en CPU.
• Máximo numero de procesos.
• Máximo numero de logins en el sistema.
• Máxima prioridad permitida a un proceso.

El administrador deberá modificar el archivo /etc/security/limits.conf para administrar estos limites, mientras que los usuarios podrán jugar con el comando ulimit para mover sus valores dentro del rango permitido. El archivo de configuración se arma con registros de cuatro campos, de izquierda a derecha son los siguientes:

Campo 1 - Dominio: Se debe especificar el usuario o el grupo al que se aplicara el limite.
Campo 2 - Tipo: Hard o soft, el primero es el limite del cual el usuario no podrá pasar mientras que el segundo es el valor por defecto que tomara el usuario tras hacer login. El carácter "-", indica que se aplican los dos tipos simultáneamente con el mismo valor.
Campo 3 - Item: El recurso que se desea limitar (core, data, fsize, memlock, nofile, rss, stack, etc).
Campo 4 - Value: Valor que se va a asignar al recurso.

Dado el siguiente archivo de configuración, comentaremos algunas cosas

martin           hard   nofile           4096
martin           -      nproc            512

Tenemos dos ítem: nofile y nproc (numero máximo de archivos abiertos y máximo numero de procesos). Después de que el usuario martin inicia sesión podría consultar los valores que tiene asociados con los comandos ulimit -n y ulimit -u, además de ver la lista de ítems completos y sus valores con ulimit -a. En este caso los valores mostrados serian de la siguiente manera:

open files (-n) 1024
max user processes (-u) 512

El usuario puede crecer nofile hasta 4096, pero no mas de ese valor, sin embargo, nproc ya no puede crecer mas, si se intenta se conseguirá un mensaje "no se puede modificar el límite: Operación no permitida".

Finalmente en la figura, verificamos esta información para el máximo numero de procesos, tratando de colgar el sistema con una bomba fork, la cual funciona con recursividad tratando de llevar los procesos hasta que el sistema deje de responder, con aplicado este limite podemos evitar esto.

Liberación de recursos & | dispositivos ocupados en GNU/Linux

Tengo que reconocer que cuando comenze a dar mis primeros pasos en GNU/Linux y que tenia necesidad de liberar algun recurso me encontre con la siguiente leyenda:

En aquellos años penosamente tenia que reiniciar para liberar. Lo que en aquellos años no sabia es que con la ayuda del comando lsof, podemos apoyarnos para revisar archivos abiertos. Este comando nos muestra en columnas los siguientes campos relacionados a un proceso:

• Comando.
• Id del Proceso ( PID )
• Usuario.
• Nombre del nodo.
  

Aqui lo que nos puede resultar util es el nombre del nodo y el PID. Por ejemplo, supongamos que queremos liberar el lector optico para leer otro disco y a pesar de que cerramos nuestras aplicaciones no podemos desmontar. El cdrom estara asociado al nodo /dev/cdrom y montado en /media, nosotros podriamos hacer lo siguiente:

lsof | grep /media

El cual nos mostrara los procesos que estan haciendo uso de este recurso y asi podriamos matarlos con kill, para cada proceso y subproceso que se muestren. ¿y si son muchos? Podemos usar el nuevo juguete que me paso mi amigo Daniel Mtz.

for cadauno in ` lsof | grep /media | awk '{ print $1 }' `; kill $cadauno 2> /dev/null ; done

Con esto automatizamos para que cada proceso encontrado sea eliminado. Este comando y sus parámetros pueden hacer muchas cosas por nosotros, para concluir veamos algunos ejemplos:

#Archivos abiertos del PID 1
lsof -p 1

#Procesos que estan usado el puerto TCP 22 y UDP 53
lsof -i :22
lsof -i UDP:53

Catching process from devil with Bash

Cuando se tiene la necesidad de buscar procesos que consuman mucho recurso de computo como memoria o cpu, pero una limitante es lo poco practico de estar detras del comando top todo el tiempo, se nos obliga a pensar el automatizar esta busqueda y que asi nos de tiempo de salir a comer algo o dormir un poco.

En esta ocacion les presento un script que nos ayuda a buscar procesos que consumen mas de 50% de cpu y nos guarda en una bitacora la informacion de este procesos. Desde luego que se le pueden hacer mejoras pero las dejaremos al criterio del usuario. Espero les sea de utilidad.

#!/bin/bash
#Variable para solo encontrar un proceso
status=0

while [ $status -eq 0 ] ;
do
cont=`ps aux | awk '$3>50  { print }' | wc -l`
if [ $cont -gt 0 ]; then
   ps aux | awk '$3>50  { print }' >> procesos.txt
   date >> procesos.txt
   #Podriamos ponerlo a 1 para solo encontrar 1 proceso
   status=0
fi

echo scanning...
#esperamos 5 minutos para volver a buscar
sleep 300
done