No se todavia si este sea el titulo adecuado para este post que por el momento no sera muy grande pero en el camino lo ire mejorando y agregando mas cosas, este no trata de dar una lista de comandos de linux, porque de esto hay mucho , sino algo de situaciones que me ha llegado a pasar, algunas cosas utiles que les podria servir, y algunos consejos para que no los lleguen a realizar , y no pierdan tiempo en ver como se arreglan los grandes problemas que se pueden llegar a ocasionar por no hacer o ver bien la funcionalidad de los comandos. Read more…

quien ha trabajado desde consola en linux, se habrá topado con varios editores de texto, entre ellos nano, pico, vi. Personalmente utilizo de preferencia VI, y a pesar de que es casi a diario aún es un poco difícil tener de memoria todo lo que este “sencillo” editor de texto nos ofrece.

 En este website pueden encontrar la referencia de esos tips que alguna vez necesitaremos al trabajar con VI:

http://rayninfo.co.uk/vimtips.html

ojo: esta actualizado al 17 de noviembre de este año.

Algo muy común en Bases de Datos es importar datos de una a otra, por ejemplo de MySQL a postgres, SQL Server a Oracle, etc. El proceso más simple a mi forma de ver es exportar todo a archivos de texto y luego importarlo de nuevo.

A veces nos topamos con el pequeño problema de que el econding del archivo esta por ejemplo en Latin1 y nuestra base de datos tiene otro encoding (UTF-8 por ejemplo).

Yo me he topado con este problema varias veces, pero usualmente usaba un editor de texto como el textpad para poder guardarlo con otra codificación, y mucho antes de darme cuenta que tenía esa opción, cambiaba caracteres como tildes, ñ, etc con un search and replace. :S.

Pero les cuento que en linux existe un comando que nos soluciona esta tarea.

El comando es iconv :

Simplemente tienen que escribir

iconv myarchivo.txt -f [encoding_actual] -t [encoding_deseado] > mynuevoarchivo.txt

Soporta larga cantidad de encodings, yo creo que todos ( pero no estoy seguro), para ver el listado escriban.

iconv -l

De todos modos lean la documentación oficial , o un simple iconv –help.

Bueno, como siempre espero que les sirva y hasta la próxima, que será dentro de unas cuantas horas. :)

 Resulta que ambos comandos, reportan de diferente forma el espacio utilizado en el disco, y para demostrar esto y entenderlo de mejor forma, lo veremos con un ejemplo, acompañados de otro comando amigo el lsof.

Si utilizamos el comando du, de la siguiente forma:


# du -sh /

el -sh significa que queremos el gran total ( s: sumarizar) y que utilice letras para definir los tamaños, MB, GB, etc.

obtenemos el siguiente resultado:

13G /

Luego utilizando el comando df, supuestamente para realizar el mismo cálculo, podriamos utilizar lo siguiente:

df -h /

el -h significa que queremos que utilice letras para definir los tamaños, MB, GB, etc.

para lo que obtendríamos un resultado como este:

Filesystem Size Used Avail Use% Mounted on
/dev/sda3   64G  30G   32G  49% /

y llegamos entonces al punto! segun du tenemos 13G utilizados en nuestro disco y el df nos dice que estamos utilizando 30GB! pregunto entonces donde se encuentran los 17GB que no estan en el disco segun el du? Bueno resulta que el “open file descriptor” es el causante de esta diferencia en resultados, ya que el df toma en cuenta los archivos abiertos y el du realiza sus calculos sobre los archivos almacenados en cada una de las carpetas recursivamente.

 Es ahora donde el “lsof” entra en juego para ayudarnos a saber qué pasa con ese crecimiento en el espacio de disco utilizado. Al ejecutar el comando de la siguiente forma:

lsof -R | more

Obtenemos un resultado como el siguiente:

COMMAND PID PPID USER FD TYPE DEVICE SIZE NODE NAME
init 1 0 root cwd DIR 8,3 4096 2 /
init 1 0 root rtd DIR 8,3 4096 2 /
init 1 0 root txt REG 8,3 32652 7028751 /sbin/init
init 1 0 root mem REG 0,0 0 [heap] (stat: No such file or directory)
init 1 0 root mem REG 8,3 9592 7260587 /lib/tls/i686/cmov/libdl-2.3.6.so
init 1 0 root mem REG 8,3 1241392 7260584 /lib/tls/i686/cmov/libc-2.3.6.so
init 1 0 root mem REG 8,3 79368 7258210 /lib/libselinux.so.1
init 1 0 root mem REG 8,3 219824 7258211 /lib/libsepol.so.1
init 1 0 root mem REG 8,3 88164 7258114 /lib/ld-2.3.6.s

utilicé el “-R” para que me listara el proceso padre y así identificar quien está utilizando dichos archivos. Con ello podemos llegar de una mejor forma a detectar ese crecimiento “fantasma”.

Como ejemplo practico podriamos hacer lo siguiente.

Primero utilicemos los siguientes comandos para el /home:

# df -h /home

# du -s -h /tmp

ahora creamos un archvo GRANDE:

# cd /home/user
# cat /bin/* >> demo.txt
# cat /sbin/* >> demo.txt

Ingresamos a otra consola y abrimos el archivo demo.txt utilizando el editor de texto vi :

# vi /home/user/demo.txt

sin cerrar vi (mantengalo corriendo en esa consola), regrese a la primer consola y borre el archivo demo.txt

# rm demo.txt

Ahora corra du y df y observará la diferencia.

# df -h /home
# du -s -h /tmp

Regrese a la siguiente consola y cierre vi sin grabar el archivo y la aparente causa principal del problema pareciera haberse resuelto, y la salida de los comandos du y df podria ya estar correcta. Este ejemplo fue solamente para “replicar” estas circunstancias en un entorno de pruebas ya que en el entorno de producción, estas diferencias se van dando por medio de los servicios que se estén ejecutando, por ello incluí el “lsof” ya que puede ayudarnos a detectar al culpable de un crecimiento en disco que pudiera llegar a “saturarlo”.

Bueno, este fué mi primer post a tipsdeaweb.com, espero volver pronto con alguno de esos tips que nos gustaría encontrar facilmente y que lo mas probable es que no esten en español.