Liberar espacio en disco – Taller Linux

Liberar espacio en discoEn ocasiones nos encontramos con que los servicios de nuestro servidor han dejado de responder o lo hacen mal. Un causa bastante común de esto es que el disco duro se ha quedado sin espacio, y esto hace que por ejemplo mysql deje de servir consultas, con lo que ya la tenemos liada.

Lo primero que debemos hacer al detectar un problema de funcionamiento en un servidor Linux remoto es ver si podemos acceder por SSH y comprobar como se encuentran la cpu, memoria y disco con los comandos top, df y demás.  Con df, si alguna de las particiones está llena lo veremos en seguida:

[root@server ~]# df -h
S.ficheros          Tamaño Usado  Disp Uso% Montado en
/dev/sda1              20G  8,6G   11G  46% /
/dev/sda2             904G   63G  797G   8% /var
tmpfs                 997M     0  997M   0% /dev/shm

Dependiendo de como esté hecho el particionamiento podremos ver diferentes entradas en esta lista, una para cada partición, existente en el disco duro o virtual. El parámetro -h nos permite visualizar los tamaños en formato “humano” más legible, si no se presentaría en kbytes.

También, existe la posibilidad de que no se haya agotado el espacio en disco, pero si los inodos. Dado que solo puede haber un fichero por inodo se podría bloquear la escritura en el disco aun cuando quedase mucho espacio libre. Para averiguar el numero de inodos ocupados y disponibles de un sistema podemos añadir el parámetro “i” a nuestra búsqueda con “df”:

[root@server ~]# df -hi 
S.ficheros           Nodos-i NUsados NLibres NUso% Montado en
/dev/sda1               1,3M    107K    1,2M    9% /
/dev/sda2                57M    315K     57M    1% /var
tmpfs                   250K       1    250K    1% /dev/shm

Como veis los sistemas de ficheros normalmente tienen una gran cantidad de inodos disponibles, pero aunque parezca imposible en según que circunstancias es posible llenarlos,  al final de la entrada explicaremos una de las maneras de que esto ocurra.

Volviendo al espacio que es lo más común, cuando una partición está llena aparece de esta forma:

S.ficheros          Tamaño Usado  Disp Uso% Montado en
/dev/sda2             904G   904G  0G   100% /var

Como se aprecia no queda espacio disponible en la partición sda2, está el 100% ocupado. Una vez detectado la causa de la parada del servicio, lo que nos queda es determinar donde están esos datos extra, liberar espacio en disco y tratar de configurar el sistema para que no vuelva a ocurrir.

Para encontrar donde se encuentran los ficheros una manera sencilla es utilizar el comando “du”. Este comando muestra lo que ocupan las carpetas y directorios, aceptando paramentos como -sch, la “s” para que no muestre subdirectorios, la “c” para que nos ofrezca el total al final, y la “h” para que lo haga “human readable”.

Al poner este comando hay que especificar una ruta donde mirar. Si la ruta acaba en “/ruta/*”, nos mostrará detalladamente lo que ocupan las carpetas de dentro de “ruta”, si acaba así “/ruta” o “/ruta/” solo mostrará el total de esa carpeta.

Por tanto para descubrir que ocupa cada subcarpeta de /var habría que poner:

[root@server ~]# du -sch /var/*
4,0K    /var/account
12K    /var/aquota.user
33G    /var/backup
268M    /var/cache
12K    /var/db
8,0K    /var/drweb
16K    /var/empty
4,0K    /var/games
1,2G    /var/lib
4,0K    /var/local
32K    /var/lock
991M    /var/log
16K    /var/lost+found
0    /var/mail
240K    /var/named
4,0K    /var/nis
14M    /var/opt
8,0K    /var/parallels
4,0K    /var/PMMtmp
4,0K    /var/preserve
16K    /var/proftpd.delay
473M    /var/qmail
4,0K    /var/racoon
708K    /var/run
60K    /var/spool
4,0K    /var/tmp
27G    /var/www
4,0K    /var/yp
62G    total

Como veis se muestra cada subcarpeta o fichero y su respectivo tamaño look these up. Esto, si la lista es muy larga puede hacer que nos cueste ver donde están los que más ocupan, un truco para solo visualizar las carpetas que superen el Giga es usar el comando grep y filtrar  por “G” de Gigas. Solo mostrará cuando haya alguna carpeta que contenga la “G” mayúscula:

[root@server ~]# du -sch /var/* |grep "G"
 33G    /var/backup
 1,2G    /var/lib
 27G    /var/www
 62G    total

Una vez detectada la carpeta que puede tener un exceso de tamaño podemos volver a repetir la operación añadiéndola a la ruta que hemos usado antes:

[root@server ~]# du -sch /var/backup/* |grep "G"
33G    /var/backup/custom
33G    total

Lo que nos mostrará otra lista de carpetas con su respectivo tamaño. Una vez hayamos encontrado los ficheros que han ocasionado el problema será necesario moverlos, eliminarlos o reducirlos, según de que se trate, y tomar las medidas necesarias impedir que vuelva a ocurrir lo mismo.

Una vez eliminados podemos utilizar de nuevo el comando “df -h” para ver si el sistema de ficheros ya nos muestra tamaño disponible, y acto seguido recomendamos reiniciar todos los servicios afectados.

A veces después de eliminar los ficheros, si estos estaban siendo utilizados de alguna forma por el sistema, es posible que aunque el fichero ya no se muestre, el espacio siga estando ocupado y nuestro servidor seguirá sin funcionar correctamente.

Para determinar cuales son estos ficheros y liberar el espacio podemos utilizar el comando “lsof +L1” que nos mostrará los ficheros abiertos pero que ya no están enlazados al sistema, es decir que han sido marcados como borrados pero aun hay alguna aplicación que los está utilizando.

[root@server ~]# lsof +L1
COMMAND     PID   USER   FD   TYPE DEVICE    SIZE NLINK   NODE NAME
mysqld     4432  mysql    4u   REG    8,1       0     0 376834 /tmp/ibwZB0zu (deleted)
mysqld     4432  mysql    5u   REG    8,1     607     0 376844 /tmp/ibgjSOHT (deleted)
mysqld     4432  mysql    6u   REG    8,1       0     0 376845 /tmp/ibQLmDPi (deleted)
mysqld     4432  mysql    7u   REG    8,1       0     0 376846 /tmp/ibOXpa96 (deleted)
mysqld     4432  mysql   11u   REG    8,1       0     0 376847 /tmp/ib43kKjz (deleted)
smartd     4813   root  txt    REG    8,1 2384848     0 180658 /usr/sbin/smartd (deleted)
sw-engine 31645 psaadm    3u   REG    8,1       0     0 655362 /tmp/.apc.l2a6sN (deleted)
sw-engine 31645 psaadm    4u   REG    8,1       0     0 655363 /tmp/.apc.a1EXf4 (deleted)
sw-engine 31645 psaadm    5r   REG    8,1       0     0 655364 /tmp/.apc.9IfP2k (deleted)
sw-engine 31645 psaadm    6u   REG    8,1       0     0 655365 /tmp/.apc.2NuHPB (deleted)
sw-engine 31645 psaadm    7r   REG    8,1       0     0 655366 /tmp/.apc.DASzCS (deleted)
sw-engine 31645 psaadm    8u   REG    8,1       1     0 655367 /tmp/sw-engine-fcgi-accept-stamp.6TYYs9 (deleted)

En la columna “SIZE” se nos informa del tamaño de dicho fichero, y a través del “COMMAND”, el “USER”  y el “PID” podremos determinar que servicio es el que los tiene retenidos.

Si necesitamos urgentemente liberar ese espacio en disco podemos hacerlo de dos maneras, una matando el proceso que lo tiene abierto o reiniciando el sistema, o dos si no es posible hacer esto pues podemos vaciarlo manualmente de la forma siguiente:

1. Buscamos la ruta real del fichero, es la última columna, para el ejemplo utilizaremos “/tmp/ibgjSOHT” que ocupa 607. Para ello usaremos el PID y el FD de la lista sacada por el lsof, en este formato “/proc/PID/fd/FD”, y comprobamos que es así con un “ls -l”:

[root@server ~]# ls -l /proc/4432/fd/5
lrwx------ 1 root root 64 feb  6 10:42 /proc/4432/fd/5 -> /tmp/ibgjSOHT (deleted)

El destino del enlace debe corresponder con el fichero mostrado del lsof, y ademas ya nos indica que el fichero está marcado como “deleted”.

2. Machacaremos el fichero con la salida de /dev/null (es decir que lo vaciamos):

[root@server ~]# cat /dev/null > /proc/4432/fd/5
[root@server ~]# lsof +L1 |grep ibgjSOHT
mysqld    4432  mysql    5u   REG    8,1       0     0 376844 /tmp/ibgjSOHT (deleted)

Y ahora el fichero que ocupaba espacio ha pasado a ocupar 0, problema solucionado. En el caso de que hubiera muchos ficheros, este sistema manual habría que automatizarlo con un script, o bien ir pensando en parar el servicio que tiene abiertos los ficheros.

Y hasta aquí hemos llegado con esta entrada, las causas más comunes de exceso de recursos suelen ser por backups descontrolados, colas enormes de spam, lo que puede superar el limite de inodos, o logs de visitas/errores que crecen descontroladamente, aquí hemos llegado a verlos de 700Gb, pero esto ya forma parte de otro artículo.

Si tienes problemas de este tipo y no consigues solucionarlos por ti mismo te recomendamos contactar con un administrador especializado, nosotros ofrecemos estos servicios, visita nuestra página y pide presupuesto sin ningún compromiso.

Un saludo.

Detectar fallos de hardware (Parte 1) – Taller Linux

Hardware FaultEn esta semana en Taller Linux vamos a explicaros las formas más comunes de detectar fallos de hardware y como tratarlos en un servidor linux al cual no tenemos acceso físico. Primero para clarificar mejor vamos  a definirlos en dos categorías. A los problemas que hacen que un sistema no esté online, es decir no tenemos acceso a los servicios o SSH los llamaremos de tipo A. Y las incidencias donde el sistema aun está online y podemos acceder por SSH, pero por ejemplo de vez en cuando se reinicia, o se caen servicios, etc.. a estos los llamaremos de tipo B.

Por tanto, ante cualquier problema el primer paso es intentar acceder como administrador al sistema por SSH y determinar de que tipo es. Si no podemos acceder será de tipo A y si entramos y nos deja ejecutar comandos lo pondremos de momento en el tipo B accutane price.

TIPO A (No podemos acceder)

Para los de tipo A lo primero que tenemos que hacer es tratar de reiniciar el servidor. La mayoría de proveedores permiten esto, e incluso algunos permiten hacer un soft reset (en caliente), donde se le indica al sistema operativo que debe reiniciarse. También, si el proveedor lo permite es mejor arrancar el sistema en un modo rescate que no use el disco duro, para poder hacer pruebas y revisarlo más detenidamente, luego explicaremos lo que se puede hacer en este modo.

En caso que al reiniciarlo o activar el modo rescate siga sin estar accesible por el puerto de administración, ya será necesario contactar con el soporte que tengamos en el centro de datos ya que por nuestra parte no hay nada mas que podamos hacer.

Respecto a los reinicios en frío nos gustaría comentar dos cosas, la primera es que no hay que abusar de ellos porque son perjudiciales para el hardware. Suponen un corte en la alimentación de los dispositivos utilizados y esto puede generar más problemas, normalmente en discos duros pero también en el resto. Lo segundo es que al reiniciar un sistema linux, si este llevaba mucho tiempo encendido, es posible que necesite chequear automáticamente la estructura de ficheros en los discos y el arranque tarde un tiempo en completarse. Por tanto si se ha reiniciado de forma normal (no en modo rescate) habrá que esperar al menos de 30 a 60 minutos de inactividad para contactar con el soporte del proveedor. Por esto siempre es mejor arrancarlo en modo rescate si se tiene la posibilidad.

TIPO B (Podemos acceder)

Si por el contrario podemos acceder, estamos ante un problema tipo B que puede o no ser de hardware, aun tendremos que determinarlo. Cosas que podemos hacer:

  • Ver si ha quedado registrado algún error.

Para ello debemos ver las entradas sospechosas en el log del sistema, que suele ser el fichero /var/log/syslog o /var/log/messages. Lo normal es buscar por fecha y hora sabiendo cuando ha empezado el problema que nos ha llevado hasta aquí.

Si no sabemos con exactitud cuando buscar podemos filtrar por la palabra error, por ejemplo:

grep -i error /var/log/messages

Y aquí nos tendría que salir alguna cosa para determinar de donde proviene el fallo,

  • Utilizar SMART para buscar errores en los discos duros

Si los discos duros soportan la tecnología SMART es posible ver su estado de forma muy fácil, utilizando el comando:

smartctl -a /dev/dispositivo
  • Visualizar los sensores de temperatura, rpm y demás que haya configurados en el sistema.

Para ello podemos instalar la aplicación lm-sensors que suele estar en los repositorios de las distribuciones más usadas.

Si con todo esto seguimos sin detectar que puede estar sucediendo convendría arrancar el  sistema en modo rescate o de alguna forma que nos permita desmontar el disco duro y revisarlo a fondo sin todos los servicios en funcionamiento. Esto lo dejaremos para la segunda parte de este taller linux sobre como detectar fallos de hardware..

Un saludo

Instalar Nginx en Centos

Instalar Nginx en CentosNginx es un servidor web moderno que esta teniendo un gran éxito últimamente. En nuestro caso lo necesitábamos coexistiendo en un servidor con Plesk junto a Apache, pero en otro puerto. Si además queremos que pueda ejecutar php es necesario añadir un módulo llamado php-fpm.

Para instalar nginx en centos  utilizaremos los repositorios atomic y epel que lo tienen disponible. Estos repositorios necesitan ser instalados con sus respectivos scripts:

wget -q -O - http://www.atomicorp.com/installers/atomic | sh
rpm -Uvh http://mirror.uv.es/mirror/fedora-epel/6/i386/epel-release-6-7.noarch.rpm

Una vez instalados para utilizarlos debemos activarlos o bien en el fichero .repo o bien directamente en el gestor de paquetes yum:

yum --enablerepo=atomic --enablerepo=epel install nginx php-fpm

Si va todo bien solo nos quedará configurarlos. Primero necesitamos saber el hostname de la máquina, podemos averiguarlo con:

hostname

Con este nombre hay que modificar el fichero /etc/nginx/conf.d/default.conf.

vim /etc/nginx/conf.d/default.conf

Aquí dentro debemos cambiar el puerto, si es queremos hacerlo, el server_name, y añadir los parámetros para la conexión con php-fpm. En nuestro caso queda tal que así pero cambiando el hostname:

server {
      listen       81;
      server_name  hostname;
      #charset koi8-r;
      #access_log  logs/host.access.log  main;
      location / {
          root   /usr/share/nginx/html;
          index  index.php index.html index.htm;
          location ~ \.php$ {
              root           /usr/share/nginx/html;
              fastcgi_pass   127.0.0.1:9000;
              fastcgi_index  index Find Out More.php;
              fastcgi_param  SCRIPT_FILENAME   $document_root$fastcgi_script_name;
              include        fastcgi_params;
          }
      }

Una vez modificado es necesario además cambiar el parámetro cgi.fix_pathinfo a 0 en nuestra configuración php existente, esto se hace en el php.ini general:

vim /etc/php.ini

Modificamos:

cgi.fix_pathinfo=0

Ahora pasamos a configurar el php-fpm, es necesario modificar el usuario y grupo por nginx:

vim  /etc/php-fpm.d/www.conf
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

Ahora añadimos los dos nuevos demonios al arranque automatico utilizando la herramienta chkconfig:

chkconfig nginx --add
chkconfig nginx on --level 235
chkconfig nginx --list
nginx          	0:desactivado	1:desactivado	2:activo	3:activo	4:desactivado	5:activo	6:desactivado
chkconfig php-fpm --add
chkconfig php-fpm on --level 235
chkconfig php-fpm --list
php-fpm        	0:desactivado	1:desactivado	2:activo	3:activo	4:desactivado	5:activo	6:desactivado

Y los activamos:

service php-fpm start
service nginx start

Si todo ha ido bien tendremos los servicios corriendo en sus respectivos puertos, el 9000 para php-fpm:

]#lsof -i :9000
COMMAND   PID  USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
php-fpm 17986  root    7u  IPv4 462059545      0t0  TCP localhost.localdomain:cslistener (LISTEN)
php-fpm 17987 nginx    0u  IPv4 462059545      0t0  TCP localhost.localdomain:cslistener (LISTEN)
php-fpm 17988 nginx    0u  IPv4 462059545      0t0  TCP localhost.localdomain:cslistener (LISTEN)
php-fpm 17989 nginx    0u  IPv4 462059545      0t0  TCP localhost.localdomain:cslistener (LISTEN)
php-fpm 17990 nginx    0u  IPv4 462059545      0t0  TCP localhost.localdomain:cslistener (LISTEN)
php-fpm 17991 nginx    0u  IPv4 462059545      0t0  TCP localhost.localdomain:cslistener (LISTEN)

Y el 81 en nuestro caso para nginx.

]# lsof -i :81
COMMAND   PID  USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
nginx   10496  root    6u  IPv4 462010368      0t0  TCP *:81 (LISTEN)
nginx   10497 nginx    6u  IPv4 462010368      0t0  TCP *:81 (LISTEN)

Y con esto ya damos por concluida la entrada de instalar nginx en centos.

Un saludo!