Cristian Vicente

En servidores con limitaciones importantes de memoria, muchas veces el sistema se queda sin memoria y el señor OOM Killer decide qué proceso tiene que matar para liberar recursos. Esto puede parecer lógico pero, en ocasiones, cuando sucede continuamente y de forma aleatoria supone un serio problema, sobretodo cuando mata el proceso de MySQL, Apache o PHP.

Es por ello que, cuando intentas indagar en la raíz del problema, te encuentras con que el kernel de Linux siempre reserva memoria para las aplicaciones que lo piden sin verificar si dispone de suficiente. Por tanto, las aplicaciones pueden llegar a pedir más memoria de la que realmente existe libre y por ello OOM Killer intentará hacer hueco.

Para cambiar este comportamiento hace falta modificar el fichero «/etc/sysctl.conf», donde añadiremos estos dos parámetros:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

Con el primer parámetro forzaremos al kernel a no dar más de lo que existe y el segundo define el ratio con el que se calculará cuánto podrá dar a cada una de las aplicaciones.

Para más info podéis consultar la web del kernel de Linux.

Tienes un servidor con una gran cantidad de bases de datos y necesitas lanzar un proceso de optimización de tablas. Puedes ir una a una:

OPTIMIZE TABLE miTabla;

O hacerlo de golpe desde un terminal:

mysqlcheck -u username -p –auto-repair –optimize –all-databases

Existe la posibilidad de que nuestro servidor se vea infectado a través de software web no actualizado o parcheado correctamente. Esto implica que, a través de una vulnerabilidad de nuestro WordPress o Prestashop, por ejemplo, nuestro servidor sea comprometido y perdamos el control sobre qué es lo que ocurre en él.

Dicho software malicioso puede estar oculto en una única línea de código (sin saltos de línea) en uno de nuestro ficheros .php o incluso en un supuesto fichero de imagen del que se hace un «innocuo» include y que es ejecutado por su dueño a través de un simple navegador web.

El llamado CryptoPHP que incluye un sofisticado interfaz web de control para su dueño y que encuentra hábilmente escondido puede llegar a ser un verdadero quebradero de cabeza.

¿Cuál es la mejor forma para deshacerse de ello? Pues usando Linux Malware Detect (LMD).

Lo instalamos de la siguiente forma como root:

cd /opt

wget http://www.rfxn.com/downloads/maldetect-current.tar.gz

tar -zxvf maldetect-current.tar.gz

cd maldetect-1.5/

./install.sh

Y ahora toca configurarlo:

vi /usr/local/maldetect/conf.maldet

De ese fichero de configuración quizás queramos cambiar la dirección de email y lo siguiente:

quarantine_hits=»1″

quarantine_clean=»1″

quarantine_suspend_user=»0″

Y ya sólo queda pasarlo con el siguiente comando:

maldet –scan-all /var/www/

Podremos ver el informe (que son almacenados en /usr/local/maldetect/sess/)

maldet –report 151029-0649.24301

Para poner los archivos en cuarentena y limpiarlos usaremos los siguientes comandos:

maldet -q 151029-0649.24301

maldet -n 151029-0649.24301

Y como se queda en «/etc/cron.daily/maldet», podemos dormir un poco más tranquilos.

Intentas lanzar un script en PHP y no haces más que obtener un error del siguiente estilo:

Allowed memory size of xxxxx bytes exhausted (tried to allocate xxxxxx bytes)

Has modificado todos los ficheros de la configuración de PHP habidos y por haber:

vi /etc/php5/cgi/php.ini

vi /etc/php5/cli/php.ini

vi /etc/php5/apache2/php.ini

vi /etc/php5/fpm/php.ini

Y siempre tienes puesto que el valor sea «memory_limit = 512MB» y no hay forma de que aquello tire.

Pues tras leer una contestación en la maravillosa web de StackOverflow, resulta que el valor, en vez de ser «512MB», debería ser «536870912». La lectura recomendada del por qué está en la web de documentación de PHP.

Si te ves en la necesidad de cambiar de nombre de dominio sin previo aviso y ves que la base de datos de tu querida web tiene la dirección web antigua por todas partes, vas a tener algo de trabajo, pero no mucho.

Primero, sería bueno echar un vistazo en PhpMyAdmin para encontrar en cuántos sitios se encuentra nuestra antigua dirección utilizando su búsqueda.

Luego, tras comprobar la barbaridad que aquello supondría hacerlo a mano, realizaremos una copia de seguridad de la base de datos con las herramientas que proporciona PhpMyAdmin y, como si de un texto cualquiera se tratase, ejecutaremos el siguiente comando:

sed -i ‘s/www.antiguadireccion.com/www.nuevadireccion.es/g’ ./backupbasedatos.sql

Y sólo tendremos que restaurar la base de datos desde ese fichero que hemos tratado con sed.

Para más info sobre el comando sed, podéis consultar la web de Bruno.

Cuando estamos haciendo una copia de una carpeta que contiene una cantidad considerable de ficheros y queremos saber con certeza que no ha faltado ningún fichero por copiar, podemos lanzar el siguiente comando que nos mostrará el número de ficheros en la carpeta y subcarpetas del directorio indicado:

ls -R -1 ./micarpeta/ | wc -l

Para más info y posibilidades echad un vistazo en la web de Linux Comando.

Cuando un sistema genera una cantidad considerable de log’s y estos no están bien administrados (logrotate), puede que a la larga vayan mermando nuestro espacio en disco. Una buena forma de encontrar cuán grande es nuestro problema es realizando una búsqueda de aquellos ficheros involucrados:

find . -type f -name «*error.log» -exec du -h {} \;

El anterior comando nos mostrará el espacio ocupado por todos aquellos ficheros «error.log» que tan abundantes son en los servidores web. Y para eliminar los ficheros que nos resulten innecesarios (por ejemplo que tengan más de 60 días de antigüedad), usaremos el siguiente comando:

find . -type f -name «*error.log» -mtime +60 -delete

Una de las cosas que mayor incomodidad me producen al recibir una llamada, es no poder escuchar a mi interlocutor con suficiente volumen. Es por ello que, si poseemos un teléfono con Android, podemos amplificar un poco la potencia del altavoz.

A través de un explorador de archivos en modo «root» (Root Browser), accederemos al archivo «/system/etc/mixer_paths.xml» y buscaremos el parámetro «voice-handset» cuyo valor, en mi caso, era de 84 y que pude subir a 94 sin que se produjese distorsión sonora.

No es que se note notablemente pero sí lo suficiente como para dejar de estrujar el móvil contra tu oreja.

Parece ser que existe un bug en el kernel que provoca una funcionalidad extremadamente lenta o incluso la imposibilidad de establecer conexión a través de la Wifi en ciertos equipos que utilizan el RTL8723BE.

La solución provisional es la de descargar los drivers y compilarlos con dos sencillos comandos:

$ make

$ sudo make install

Si tienes una Raspberry Pi, has actualizado el sistema operativo y te han dejado de funcionar las cosas que tenías conectadas en el GPIO es por una sencilla razón: en el kernel 3.18 se ha activado el soporte a Device Tree.

En mi caso me había dejado de funcionar el ambilight casero que tenía y, por ejemplo, boblight me lanzaba lo siguiente por el terminal:

SPI mapped from 0x0x20204000 to 0x0x16c5000

Boblightd 2.0 (optimized version for raspberry) (c) 2013 Speedy1985 and Heven)
(InitLog) start of log /root/.boblight/boblightd.log
(PrintFlags) starting boblightd
(CConfig::LoadConfigFromFile) opening /etc/boblight.conf
(CConfig::CheckConfig) checking config lines
(CConfig::CheckConfig) config lines valid
(CConfig::BuildConfig) building config
(CConfig::BuildConfig) built config successfully
(main) starting devices
(CClientsHandler::Process) opening listening TcpSocket on 127.0.0.1:19333
(CDevice::Process) AmbiLight: starting with output «/dev/spidev0.0»
(CDevice::Process) AmbiLight: setting up
(CDeviceSPI::SetupDevice) ERROR: AmbiLight: Unable to open /dev/spidev0.0: No such file or directory
(CDevice::Process) ERROR: AmbiLight: setting up failed, retrying in 10 seconds

Y efectivamente no existía ningún /dev/spidev0.0. Indagando encontré que en algunas distros (Raspbian) el módulo spidev o spi-bcm2708 no cargaban porque estaban en el fichero «/etc/modprobe.d/raspi-blacklist.conf» y había que comentar dichas líneas. En mi caso yo no tenía ningún módulo bajo el blacklist y me cercioré que mi kernel había sido compilado con las opciones correctas:

zcat /proc/config.gz  | grep -i SPIDEV

CONFIG_BCM2708_SPIDEV=y
CONFIG_SPI_SPIDEV=y

Pero la solución a mi problema fue añadir la siguiente línea al fichero «/boot/config.txt»:

dtparam=spi=on

Reiniciar y listo.