[EN] Setting open descriptors on Ubuntu18.04

Hello! this is a tricky question; many times you are used to do something in an special way but suddenly, one day it doesn't work. That's what happened to me with open file descriptors on Ubuntu 18.04.

 By default this Ubuntu release has

esther@host:~# sudo ulimit -n
1024
esther@host:~#

which may be very little if you plan to run, for example, an nginx server. If you want to change that value, you have to

1) edit /etc/sysctl.conf and add

fs.file-max = 65535
fs.nr_open = 65535

at the end of the file

2) edit /etc/security/limits.conf and add at the end

* soft     nproc          65535   
* hard     nproc          65535  
* soft     nofile         65535  
* hard     nofile         65535
root soft     nproc          65535   
root hard     nproc          65535  
root soft     nofile         65535  
root hard     nofile         65535

3) check that 

/etc/pam.d/common-session 
/etc/pam.d/common-session-noninteractive 

contain

session    required    pam_unix.so

which is the default configuration for the pam.d service; if you need to update any of those two files, restart the pam.d service.

If you have done all of those changes, reload them and check if still have the same values

esther@host:~# sudo sysctl -p
esther@host:~# sudo ulimit -n

shows the default value, make one last change on /etc/systemd/user.conf and set

DefaultLimitNOFILE=65535

Save and restart... and check it again ;)

[EN] rc.local on Ubuntu 18.x

On Ubuntu 18.04/18.10 I have missed the rc.local file that had helped me a few (thousand) times. Have you missed it too? By default, the file does not exit, but the service behind is present, so not everything is lost.

If you want to enable this feature on your Ubuntu, you are just few steps away.

First of all, let's create the file and set the correct perms

> touch /etc/rc.local
> chmod +x /etc/rc.local

and then let's give it the correct format

> echo "#!/bin/bash
exit 0" > /etc/rc.local

and it will work. You can check the state of the service as well with

> systemctl status rc-local

and start/stop it if you want to make any test.

Error común: "Too many open files", en Tomcat o PHP

Si Tomcat os devuelve un error HTTP 500 y en el 'catalina.out' encontráis algo de este tipo

[] org.apache.tomcat.util.net.JIoEndpoint$Acceptor run SEVERE: Socket accept failed
java.net.SocketException: Too many open files

es que tenéis un problema de ficheros abiertos; con

> ulimit -a

puedes ver tu configuración actual; repasa la variable "open files" que te da cuántos ficheros abiertos puede haber por proceso. Puedes modificarla con

> ulimit -n #

donde # es el nuevo valor; prueba con 4096 y reinicia el tomcat para que coja el cambio de esta variable de sistema

Para controlar cuántos ficheros tiene un proceso abierto, lo puedes hacer con  

> lsof -l | grep tomcat

Este tipo de fallo es aplicable a cualquier otra aplicación, no sólo a tomcat; también PHP requiere abrir muchos ficheros y puede  arrojar un error similar. Tenlo en cuenta cuando una aplicación se pare de repente después de rato funcionando bien.

Gracias!

Subvolúmenes (bricks) no montan en volúmenes gluster

Para ver el estado de un volumen gluster, hago:

[root@gest ~]# gluster volume status drupriv
Status of volume: drupriv
Gluster process Port Online Pid
------------------------------------------------------------------------------
Brick 172.17.229.77:/mnt/gluster/data 49152 Y 5270
Brick 172.17.230.164:/mnt/gluster/data 49152 Y 28083
Brick 172.17.229.250:/mnt/gluster/data 49152 Y 16775
NFS Server on localhost 2049 Y 5282
Self-heal Daemon on localhost N/A Y 5295
NFS Server on 172.17.229.124 2049 Y 2287
Self-heal Daemon on 172.17.229.124 N/A Y 2292
NFS Server on 172.17.229.113 2049 Y 2327
Self-heal Daemon on 172.17.229.113 N/A Y 2332
NFS Server on 172.17.229.250 2049 Y 16788
Self-heal Daemon on 172.17.229.250 N/A Y 16796
NFS Server on 172.17.230.164 2049 Y 28096
Self-heal Daemon on 172.17.230.164 N/A Y 28104
Task Status of Volume drupriv
------------------------------------------------------------------------------
There are no active volume tasks

y lo que obtengo es:

- por un lado el estado de los bricks que forman el volumen:

Brick 172.17.229.77:/mnt/gluster/data 49152 Y 5270
Brick 172.17.230.164:/mnt/gluster/data 49152 Y 28083
Brick 172.17.229.250:/mnt/gluster/data 49152 Y 16775

- por otro lado, los servidores que están montando ese volumen (por NFS en este caso)

NFS Server on localhost 2049 Y 5282
Self-heal Daemon on localhost N/A Y 5295
NFS Server on 172.17.229.124 2049 Y 2287
Self-heal Daemon on 172.17.229.124 N/A Y 2292
NFS Server on 172.17.229.113 2049 Y 2327
Self-heal Daemon on 172.17.229.113 N/A Y 2332
NFS Server on 172.17.229.250 2049 Y 16788
Self-heal Daemon on 172.17.229.250 N/A Y 16796
NFS Server on 172.17.230.164 2049 Y 28096
Self-heal Daemon on 172.17.230.164 N/A Y 28104

En el caso de que algún subvolumen no esté online (esto es cuando en lugar de una Y
tenemos una N), podemos levantarlo de la siguiente manera (se hacen todos a la vez, no
por partes)

gluster volume start drupriv

y si falla o no los levanta, podemos llegar a forzarlos:

gluster volume start drupriv force

Una vez forzado, comprueba que se han montado todas las unidades, remonta los glusters
y debería verse todo con normalidad

Liberar la RAM cacheada en Linux

¿No os ha pasado nunca que se os ha quedado un servidor sin RAM, y que no os ha quedado otra que reinciarlo? MIra que da rabia... y más si la RAM la estás viendo cacheada y no puedes/sabes liberarla.

Pues esto se va a acabar... más o menos. Buscando por la red, localizé un blog (Redes Privadas Virtuales) que daba una solución a este problemilla, y que la verdad es que funciona muy bien. La entrada original la podéis encontrar aquí, donde se explica un poco el porqué, y yo os dejo aquí mi pequeño script que automatiza el vaciado. Lo estoy implementando en los últimos servidores en los que estoy trabajando, y de momento da bastante buen resultado.

#! /bin/sh
sync
echo 3 > /proc/sys/vm/drop_caches
echo 0 > /proc/sys/vm/drop_caches

Yo pongo la entrada correspondiente en el cron y lo ejecuto una vez al día, a ser posible por la noche, y la verdad es que se nota.

Ya me diréis qué tal os funciona!

Top 5 things you should never tell your boss

1) I pray every day that there won't be a compliance audit...
2) My "robust" config backup strategy is an Excel spreadsheet...
3) I desperately need someone to invent spell check for CLI scripting...
4) My idea of disaster recovery is updating my resume and LinkedIn profile...
5) The only real-time change alerts I receive are when you start screaming...



Cuánta verdad hay en estas líneas...