Notas sobre journal / journalctl

Algunas notas que me resultan útiles casi a diario, sobre el uso de journalctl…

Por defecto es volátil y por lo tanto no persiste tras un reboot.

Tenemos en

/run/log/journal/$ID/system.journal

Los logs de cada arranque disponible, donde $ID es un id que asigna systemd al log.

/run/log/journal/d0c4a268300a404b9cbc7a39f31a47bd/system.journal

• Consultar logs disponibles.

journalctl --list-boots 
 0 bf51a6d4b1a749dfb22eb955a2764e84 lun 2017-09-25 20:49:23 CEST

Podremos ver salidas del tipo:

-3 XXXXX3 fecha ….

-2 XXXXX2 fecha ….

-1 XXXXX1 fecha ….

0 XXXXX0 fecha ….

• Consultar logs de un boot determinado.

journalctl -b -3
journalctl _BOOT_ID=-3

• Consultar logs del kernel.

journalctl -k

• Consultar últimas entradas. 

journalctl -b -k -n 10 #(Ultimas 10 entradas de logs de kernel y boot)

• Logs de un proceso.

journalctl /bin/xxxx #(Full path)
journalctl _PID=XXXX

• Logs de un usuario.

journalctl _UID=XXXX

• Logs de un servicio.

journalctl -u httpd.service
journalctl _SYSTEMD_UNIT=httpd.service

• Logs de varios servicios.

journalctl _SYSTEMD_UNIT=XX.service + _SYSTEMD_UNIT=YY.service

• Establecer rangos de fecha.

--since=09:30
--until=16:25
--since='30 min ago'
--until='2 days ago'

• Logs por criticidades.

journalctl -p 2
journalctl -p err

0 emergency / 1 alert / 2 crit / 3 err / 4 warn / 5 notice / 6 info / 7 debug

• Logs por disco.

journalctl /dev/sda
journalctl /dev/sda1

• Check espacio usado de journal.

journalctl --disk-usage
Archived and active journals take up 8.0M on disk.

• Permitir journal a usuarios.

El grupo ‘adm‘ tiene acceso a journal.

usermod -a -G adm USUARIO

• Configurar persistencia de logs.

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
chown root:systemd-journal /var/log/journal
chmod 2775 /var/log/journal
systemctl restart systemd-journal

• Configuración general.

En el fichero:

/etc/systemd/journald.conf

Storage=

volatile –> Es volatil en /run/systemd/journal/

Persistent –> Es persistente en /var/log/journal/

Auto  –> Por defecto persistente, pero si no esta el path NO lo crea y pasa a volatil.

Nohe –> Logs a consola

Compress=  –> Por defecto true

Seal= –> Se crean claves para asegurar la integridad de los logs.

SystemMaxUse= 50M #(Por defecto 10% de filesystem, tamaño al que rota)

• Rotado manual.

journalctl --vacuum-size=2G #(Limpiar y retener 2G)
journalctl --vacuum-time=2years #(Limpiar y retener 2 años)

Configurando Bond promisc

Hace poco he tenido la necesidad, de agregar varias interfaces  en modo promiscuo, en solo una interfaz virtual.

Ya escribí una pequeña introducción sobre configuración de bond, hace mucho tiempo, en la que se indican los distintos tipos.

En esta ocasión el modo usado es el «3» o Broadcast.

La configuración de la interfaz de bond y de sus interfaces físicas es la siguiente.

/etc/sysconfig/network-scripts/ifcfg-bond0

TYPE="Bond"
BONDING_MASTER="yes"
BOOTPROTO="none"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="bond0"
DEVICE="bond0"
ONBOOT="yes"
PROMISC="yes"
BONDING_OPTS="mode=3"
NM_CONTROLLED="no"

/etc/sysconfig/network-scripts/ifcfg-eno1

DEVICE="eno1"
ONBOOT="yes"
BOOTPROTO="none"
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="eno1"
PROMISC="yes"
MASTER="bond0"
SLAVE="yes"
NM_CONTROLLED="no"

/etc/sysconfig/network-scripts/ifcfg-eno2

DEVICE="eno2"
ONBOOT="yes"
BOOTPROTO="none"
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="eno2"
PROMISC="yes"
MASTER="bond0"
SLAVE="yes"
NM_CONTROLLED="no"

Tras esta configuración, simplemente queda garantizar que las interfaces levanten en modo promiscuo, para lo que editamos rc.local

/etc/rc.local

/sbin/ip link set bond0 promisc on
/sbin/ip link set eno1 promisc on
/sbin/ip link set eno2 promisc on

Llegados aquí podremos capturar todo el tráfico de las interfaces enoX en la interfaz bond0

Notas sobre Rsyslog

En esta nota dejaré algunos apuntes interesantes, sobre configuraciones que estoy encontrando, al hacer un uso mas intensivo de rsyslog.
Es una nota un poco desordenada, más como recordatorio que como post estructurado.

– Problemas de drops en Rsyslog por exceso de msg. RedHat 6.X –

Rsyslog define el numero de mensajes por intervalo de tiempo. Superado este umbral se producirá un dropeo y perderemos entradas.

Superar este umbral deja una entrada en los logs de la máquina, en:

/var/log/messages
Jul 5 18:51:01 localhost rsyslogd-2177: imuxsock lost 538 messages from pid 433 due to rate-limiting

Esto implica que tenemos cargado el modulo imuxsock con la librería  /usr/lib/rsyslog/imuxsock.so en el fichero /etc/rsyslog.conf

$ModLoad imuxsock

La configuración de estos intervalos se define con los parámetros :

$SystemLogRateLimitInterval 10
$SystemLogRateLimitBurst 500

Por defecto son bastante conservadores, así que podemos ajustarlos como necesitemos.

$SystemLogRateLimitInterval (Tiempo en segundos)
$SystemLogRateLimitBurst (Número de msg)

También podemos encontrar entradas equivalentes más «legacy», aunque no es lo normal:

$IMUXSockRateLimitBurst [number] - equivalent to: RateLimit.Burst
$IMUXSockRateLimitSeverity [numerical severity] - equivalent to: RateLimit.Severity
$IMUXSockRateLimitSeverity [numerical severity] - equivalent to: RateLimit.Severity

Si queremos eliminar este control podemos definir el tiempo en «0s»

$SystemLogRateLimitInterval 0

Tras los cambios, reiniciamos rsyslogd

– Problemas de drops en Rsyslog por exceso de msg. RedHat 7.X –

En RedHat 7, podemos tener este problema tanto en rsyslog como en systemd-journald, dejando en ambos casos, sus respectivos logs:

Jun 28 03:08:43 localhost systemd-journal[1864]: Suppressed 917 messages from /

o

Jun  28 10:32:15 localhost rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting
Jun  28 10:32:17 localhost rsyslogd-2177: imjournal: 236 messages lost due to rate-limiting

Para systemd-journald, editamos /etc/systemd/journald.conf casi como en el caso anterior

RateLimitInterval= (Tiempo en segundos)
RateLimitBurst= (Numero de msg.)

Tras los cambios, reiniciamos systemd-journald

Para rsyslog y con el formato tradicional, como en el caso de RedHat 6, editamos, /etc/rsyslogd.conf

$imjournalRatelimitInterval = (Tiempo en segundos)$imjournalRatelimitBurst = (Numero de msg)

También podemos encontrar esto, aunque aun no lo he visto.

if rsyslog.conf has been modified to use new-style module-loading syntax, well, stick with thatExample excerpt:
module(load=»imjournal» StateFile=»/var/lib/rsyslog/imjournal.state» ratelimit.interval=»300″ ratelimit.burst=»30000″)

Tras los cambios, reiniciamos rsyslogd

– Problemas por  tamaño de msg. –

También podemos tener problemas con el tamaño de msg. tanto para recibir como para enviar, si este supera el valor por defecto. 2k
UDP soporta un valor máximo de 4k

testing showed that 4k seems to be the typical maximum for UDP based syslog. This is an IP stack restriction. Not always … but very often.

Más detalle (aquí), así que si queremos tamaños mayores debemos usar TCP.
Por ejemplo, los registros de sucesos de windows tienen tamaños de hasta 64k
Si detectamos msg incompletos, deberemos ajustar el tamaño máximo, usando la directiva:

$MaxMessageSize (Tamaño en bytes)

Tras los cambios, reiniciamos rsyslogd

Configurando VLAN tagging sobre Bond

No hace mucho, he tenido que configurar un bond con tagging y he tenido algunos problemas que me parece buena idea, dejar por escrito.

La configuración de una interfaz «tagueada» con el id de una VLAN, no tiene más complicación. Existe mucha documentación al respecto.

Defines tu fichero de interfaz ifcfg-eth0 y su copia «link» con un «.» seguido del vlan_id…. ifcfg-eth0.10 (En este fichero, se define la configuración de red y se añade la clausula «VLAN=yes»)

Hasta aquí, todo según la documentación….

Al combinar, bond y tagging, es cuando he tenido estos problemas principalmente:

1.- Para vlans, necesitamos el modulo 8021q, el cual no carga por defecto, por lo que creamos un fichero /etc/modules-load.conf/8021q.conf

8021q

2.- Según la documentación consultada, desde la versión 6.3 de CentOS, existen problemas con bonding+tagging y NetworkManager. En los «bug reports» se recomienda que se pare NetWorkManager.

Estas pruebas se han realizado con CentOS 7.2 y tenia el mismo problema.

3.- Al parar NetworkManager, el modulo de bond no se carga al arranque. Para esto, tenemos dos alternativas:

3a.- Definir la carga del modulo creando un fichero en /etc/modprob.d/bond.conf

alias bond0 bonding
options bond0 miimon=100 mode=0

El detalle de los modos disponibles, lo tenéis aqui

3b.- Definir en el fichero de configuración del bond, la opción BONDING_OPTS:

BONDING_OPTS="mode=balance-rr miimon=100"

Esto hace que el modulo se cargado al arranque
Tras esto, la configuración siguiente funciona sin problemas:

ifcfg-eno1

TYPE="Ethernet" BOOTPROTO="none" NAME="eno1" DEVICE="eno1" ONBOOT="yes" NM_CONTROLLED="no" MASTER="bond0" SLAVE="yes"

ifcfg-eno2

TYPE="Ethernet" BOOTPROTO="none" NAME="eno2" DEVICE="eno2" ONBOOT="yes" NM_CONTROLLED="no" MASTER=bond0 SLAVE=yes

ifcfg-bond0

TYPE="Bond" BOOTPROTO="none" DEVICE="bond0" NAME="bond0" ONBOOT="yes" BONDING_OPTS="mode=balance-rr miimon=100" NM_CONTROLLED="no"

ifcfg-bond0.10

BOOTPROTO="none" DEFROUTE="yes" NAME="bond0.10" DEVICE="bond0.10" NM_CONTROLLED="no" ONBOOT="yes" IPADDR="192.168.1.23" PREFIX="24" GATEWAY="192.168.1.1"DNS1="8.8.8.8"DNS2="8.8.4.4"BONDING_MASTER=yes VLAN="yes"

Con esto tendremos nuestro bond «tagueado» con el id de la vlan, como vemos a continuación.

# ip -d link show bond0.107: bond0.10@bond0: UP> mtu 1500 qdisc noqueue state UP mode DEFAULT     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff promiscuity 0     vlan protocol 802.1Q id 10 addrgenmode eui64

[root@XXXXnetwork-scripts]# ip a l 1: lo: ...2: eno1: LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 3: eno2: LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 4: ...5: ...6: bond0: UP,LOWER_UP> mtu 1500 qdisc noqueue state UP     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff     inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link        valid_lft forever preferred_lft forever 7: bond0.10@bond0: UP> mtu 1500 qdisc noqueue state UP     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff     inet 192.168.1.23/24 brd 192.168.1.255 scope global bond0.10
       valid_lft forever preferred_lft forever     inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link        valid_lft forever preferred_lft forever

Networking con Docker – docker0 bridge…. Y si coincide

He estado realizando unas pruebas con docker y me he encontrado con lo siguiente..

La red que usa docker como bridge 172.17.0.0 /16 coincide con la red del segmento en el que se aloja la máquina de pruebas. Por lo que al arrancar el demonio de docker la interfazdocker0, dejaba la máquina no accesible.

Leyendo un poco, hay varias formas de abordar esto…. podemos pasarle a docker, parámetros para indicarle que red bridge debe usar, por lo que nuestra interfaz docker0, sera creada en dicho segmento.

Sin embargo, me parece más sencillo, el segundo mecanismo que viene a indicar, que si tenemos una interfaz docker0 en la máquina anfitrión, al arrancar docker, usará esta interfaz para la red bridge. De este modo no hay que indicarle nada en el arranque a docker.

1.- Desde consola.
Si hemos arrancado docker, aunque paremos el servicio, ya tendremos la interfaz docker0, tumbamos la interfaz:

systemctl stop docker.service
ip link set dev docker0 down

Modificamos la red.

ip addr add 172.19.0.0/16 dev docker0
ip link set dev docker0 up

Con esto al arrancar docker, este usara la nueva interfaz docker0 en la red 172.19.0.0

2.- Mismo concepto pero desde fichero.
(Centos7) Creamos el fichero para la interfaz docker0:

/etc/sysconfig/network-scripts/ifcfg-docker0

DEVICE=docker0
TYPE=Bridge
IPADDR=172.19.0.1
NETMASK=255.255.0.0
ONBOOT=yes
BOOTPROTO=none
NM_CONTROLLED=no
DELAY=0

De este modo dejaremos el cambio persistente.

Notas sobre DM-Multipath.

Hace un par de días, tras unos problemas con algún sistema que otro, un compañero me hizo llegar una nota de oracle sobre multipath, que me parece de lo más claro que he leído sobre  esto, en bastante tiempo.
Oracle Doc ID: 470913.1

Como tengo una memoria «privilegiada»…. prefiero apuntar estas notas sueltas, que en conjunto, parece que hasta tienen sentido.

Device-Mapper Multipath (DM-Multipath)

Es una herramienta nativa en linux la cual permite configurar múltiples caminos entre un host y un array de almacenamiento, como si de uno solo se tratara.

Supongamos que vemos la cabina de discos por 4 caminos desde nuestra máquina….
Al ofrecer un disco a la máquina, esta vería 4 discos o cuatro caminos a un disco:

/dev/sdc
/dev/sdd
/dev/sde
/dev/sdf

Multipath realiza la ‘agregación’ o ‘mapeo’, para que podamos trabajar con un dispositivo único (Aunque le da 3 nombres):

"/dev/dm-0" o "/dev/mpath/mpath0" o "/dev/mapper/mpath0"

Según la documentación consultada funciona como una tabla de ‘mapeos’:
‘1’ Mapped device <–> Mapping Table <–> ‘N’ Target device

Como hemos comentado, para cada agregación de caminos, se crean 3 dispositivos (nombre de dispositivo), y aquí viene el problema….. Cual uso, para que y porque.

1.- /dev/dm-X
Este dispositivo es para uso interno de DM-Multipath
NUNCA se debe usar este dispositivo.

2.- /dev/mpath/mpathX
Alias en formato «humano». Se usa para tener agrupados los discos en un mismo directorio «/dev/mpath/»
NUNCA se debe usar este dispositivo, ya que en el arranque UDEV, puede no ser capaz de crear los dispositivos, lo suficientemente rápido, por lo que no estarán disponibles para ser montados.

3.- /dev/mapper/mpathN
Este es el dispositivo que debemos usar ya que es persistente y se crean al arrancar usando el driver device-mapper.
Podemos usar este driver para crear dispositivos lógicos usando «dmsetup»

Nota: Indicar que en distintas máquinas el nombre recibido puede ser diferente, si se quiere garantizar el mismo nombre, deberemos usar UDEV/Multipath y su wwid, para fijarlo.

Por ejemplo:
Single Path:

Obtener UUID
------------------
#scsi_id -g -s /block/sdc
3600a0b8000132XXXXXXXXXXXXb625e
Luego en UDEV
------------------
Editamos:
'/etc/udev/rules.d/10-local.rules'
...
KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="3600a0b8000132XXXXXXXXXXXXb625e", NAME="sda%n"
...

Multipath

Obtener WWID
---------------
multipath -ll
...
mpath1 (360060480000XXXXXXXXXX23544343331)
...
Luego en "multipath.conf"
--------------------------
multipaths {
...
...
multipath {
wwid
360060480000XXXXXXXXXX23544343331
alias NOMBRE
}
...
...

Nota2: Trabajando con dispositivos bajo UDEV, podemos obtener problemas de permisos, que no entraré a detallar, ya que no los he «sufrido», simplemente citar que las definiciones de permisos, se realizan, en la creación del dispositivo, tal y como hemos visto antes, en su linea dentro de «rules.d», añadiendo:

....., OWNER="Nombre_USUARIO", GROUP="Nombre_GRUPO", MODE="0660"

Creando particiones.
Una vez aclarado que debemos usar el dispositivo desde «/dev/mapper/…» y porque. Creamos la partición usando «fdisk»

fdisk /dev/mapper/mpath0

Esto creará la entrada en la tabla de particiones, pero no en los dispositivos que forman la agrupación de discos.
Ni generará los ‘mapeos’ necesarios en «/dev»
Para registrar estos cambios y generar los ‘mapeos’, usamos kpartx que es parte de multipath-tools .

kpartx -a /dev/mapper/mpath0
partprobe

Esto nos creará el ‘mapeo’ en «/dev» para cada partición creada:

/dev/mapper/mpath0p1
/dev/mapper/mpath0p2
/dev/mapper/mpath0p3
...

A este dispositivo (/dev/mapper/mpath0p1), podemos darle formato como a cualquier partición.

Flags útiles:
Para ver las particiones de un device:

kpartx -l /dev/mapper/mpath0
mpath0p1 : 0 2295308 /dev/mapper/mpath0 61

Ver que información hay en la tabla de particiones para ser escrita con «kpartx -a»

kpartx /dev/mapper/mpath0

Referencias del post:
Blogs:
http://www.celtha.es/blog/howto-configuracion-multipath/
http://clemente.pamplona.name/dba/manejo-de-asm-multipath-y-asmlib/

RedHat:
https://www.centos.org/docs/5/html/5.2/Virtualization/sect-Virtualization-Virtualized_block_devices-Configuring_persistent_storage_in_a_Red_Hat_Enterprise_Linux_5_environment.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/DM_Multipath/mpath_devices.html
https://access.redhat.com/documentation/es-ES/Red_Hat_Enterprise_Linux/6/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-6-DM_Multipath-es-ES.pdf
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-7-DM_Multipath-en-US.pdf

Oracle:
Nota 394956.1
Nota 371814.1
Nota 456239.1

Dedicado a las dos ‘chicas’ de la casa, por aguantar mis horas de curro/hobby en casa.

Update Owncloud – Ventana mantenimiento.

Tras el último update con aptitude, al acceder vía web a mi owncloud, me he encontrado con un mensaje indicando que estaba en mantenimiento.
No es la primera vez que me sucede, aunque normalmente funciona correctamente, así que me dejaré este post…

Nota: El acceso desde la app de android era correcto.

Para solucionarlo he usado el comando:

cd /var/www/owncloud
sudo -u www-data php occ maintenance:mode --off

Aquí tenemos más comando útiles.
Tras esto, al acceder vía web, nos indica que tenemos disponible el update, y si lo lanzamos, actualiza la bbdd y funciona perfectamente.

Tuning BD – Cálculo inicial.

En determinadas ocasiones he tenido que realizar un tunning, básico y rápido (seguro que también malo, pero…. ni soy dba ni lo pretendo)

Se que los cálculos genéricos no son el camino, pero aveces no hay mas remedio.
El siguiente script, pretende ofrecer algunos valores calculados sobre el HW de la maquina, y ofrecer algún posible calculo.

Básicamente se ha convertido en un compendio de formulas para tratar de ajustar el rendimiento.
Como curiosidad no esta mal.

NOTA: El script no era el fin, en si mismo…. son ordenes básicamente secuenciales….. 🙂
script

NOTA2: Esto empezó en un post anterior Aquí.

Consumo de Memoria y Caches

Hace unos días he visto un caso curioso sobre un Centos7.
El caso es que la máquina tenia un consumo de memoria que rondaba el 95% y tras un análisis rápido, la memoria no aparecía como cacheada, por lo que suponía que estaba realmente siendo usada.
Lo siguiente fue, ver que proceso / procesos estaban haciendo uso de esta cantidad de memoria, y la sorpresa fue, que no me cuadraban los valores, «faltaban» más menos 7Gb de 8Gb…. ¿?
Tras revisar en detalle la salida de /proc/meminfo, observé esto:

...
Slab:            6903676 kB
...
SReclaimable:    6873888 kB

Aunque la máquina no tenia problemas de rendimiento, por motivos que vienen al caso, no podía llegar a estos umbrales aunque la memoria estuviera como «reclamable»….

Como evitar esto?
Hay muchos posts sobre esto, así que citaré alguno de los que consulté.

https://major.io/2008/12/03/reducing-inode-and-dentry-caches-to-keep-oom-killer-at-bay/
http://www.blackmoreops.com/2014/10/28/delete-clean-cache-to-free-up-memory-on-your-slow-linux-server-vps/

Resumiendo….
Tenemos el fichero:

/proc/sys/vm/drop_caches

Que admite los siguientes valores:

0 » Cede el control al Kernel para que administre la memoria

1 » Libera pagecache

2 » Libera dentries y inodes

3 » Libera pagecache, dentries y inodes

Nota:

Pagecache: Paginación en memoria caché

Dentries: Directory entries, relación estructurada entre directorios y ficheros

Inodes: Índice de archivos utilizado por el sistema de ficheros dónde almacena los metadatos de cada archivo (tipo, propietario, permisos, fecha de creación....)Esto se puede ejecutar manualmente o programar en el cron:

EJECUCIÓN MANUAL

#sync ; echo 0 > /proc/sys/vm/drop_caches
#sync ; echo 1 > /proc/sys/vm/drop_caches
#sync ; echo 2 > /proc/sys/vm/drop_caches
#sync ; echo 3 > /proc/sys/vm/drop_caches

CRON

00 04 * * * /bin/sync; /bin/echo 2 > /proc/sys/vm/drop_caches

También podemos configurar esto vía sysctl:

sysctl -a|grep -i cache

Podemos modificar, que  queremos vaciar como

vm.drop_caches = 0

NOTA
Además de esto, también existe el parametro:

vfs_cache_pressure

Este valor indica la prioridad con la que se reclamará la cache de de (inodos/dentry) frente a la de datos (pagecache).
Por defecto tiene un valor de «100»

• Si se decrementa, se preferirá reclamar (pagecache).
• Si se incrementa, se preferirá reclamar (inodos/dentry).
• Un valor de «0» hará que nunca se reclame, por lo que acabaríamos provocando un out of memory.

Notas OOM Killer – Out Of Memory

Introducción.

Habitualmente los procesos solicitan una reserva de memoria superior a lo que necesitan usar, debido a esto el kernel tiene la habilidad de hacer «over-commit» o lo que es lo mismo… asignar más memoria de la que tiene físicamente el sistema, considerando que normalmente los procesos no llegarán a usar esta.
Cuando los procesos si llegan a usar la memoria que han reservado, el kernel ha de comenzar a matar procesos para poder mantenerse operativo. Para recuperar la memoria necesaria el kernel usa «out-of-memory killer» o «OOM killer».

Detección y Análisis.
Algunas veces hemos visto procesos que dejan de estar en ejecución o simplemente vemos los famosos mensajes por pantalla…. «…Out of memory…»
Podemos detectar si OOM esta entrando a matar procesos revisando el log del sistema..

grep -i kill /var/log/messages*
host kernel: Out of Memory: Killed process 1324 (apache).

Si se revisa la memoria en este punto, es muy posible que no nos aporte nada, ya que OOM ya esta matando procesos para mantener la memoria que el kernel necesita, por lo que estos controles deberíamos hacerlos antes de que suceda el problema.
Dicho esto….
Podemos encontrarnos con el caso en que un sistema este matando procesos, teniendo memoria libre y sin estar usando swap…. ¿por qué?
La memoria del sistema se divide en «high memory» y «low memory»
En lineas generales tenemos distinto obgetos en cada zona…

High Memory:

• Código de procesos
• Datos de procesos

…
Low Memory:

• Buffers y Cache
• Kernel
• Procesos del kernel
• Tablas de asignación de memoria de cada proceso
• ….

El estado de la memoria es la suma de estas dos zonas.
Ya que es posible tener la «Low Memory» llena y la «High Memory» libre, podemos tener en la salida de «free -m» memoria libre y el OOM trabajando.
Para poder detallar esto tenemos:

free -lm [root@test-sys1 ~]# free -lm
total used free shared buffers cached
Mem: 498 93 405 0 15 32
Low: 498 93 405
High: 0 0 0
-/+ buffers/cache: 44 453
Swap: 1023 0 1023

Configurando comportamiento.
Una vez determinado el porque entra en acción OOM Killer, podemos realizar varias acciones….
Por un lado podemos actuar en caliente sobre los procesos, para indicarle a OOM Killer que no intente matar un determinado proceso.

Esto se realiza mediante prioridades…

Kernel 2.6.29 o superior

Prioridades: -1000 (No se eliminará) a 1000 (próximo en ser eliminado)

Kernel inferior a 2.6.29

Prioridades: -17 (No se eliminará) a 15 (próximo en ser eliminado)

Para aplicarlas basta con:

echo «-999» > /proc/[PID]/oom_adj

El automatizarlo o no…. según necesidades.

Prevenir la entrada de OOM Killer.

Para prevenir este comportamiento podemos configurar el comportamiento del kernel en cuanto a overcommit.
Existen 3 valores para overcommit_memory.

• 0 – (Defecto) Comportamiento Heurístico. Realiza estimaciones, para asignar mas memoria de la disponible.
• 1 – Sin comportamiento Heurístico. Asignación de memoria física.
• 2 – En este caso deja de tener un comportamiento heuristico, cuando se supera el consumo de la swap + un porcentaje de memoria, indicado en «overcommit_ratio», por lo que siempre tendremos un % de memoria no usada para el overcommit.

Una buena práctica sería, por ejemplo (En este ejemplo, el 20% de la memoria no se usaría en el overcommit):

vi /etc/sysctl.conf
vm.overcommit_memory = 2vm.overcommit_ratio = 80

Luego ejecutamos «sysctl -p»

Links relacionados.
http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html
https://www.kernel.org/doc/gorman/html/understand/understand012.html
http://rm-rf.es/como-excluir-un-proceso-del-oom-killer

http://www.ecsl.cs.sunysb.edu/elibrary/linux/mm/mm.pdf

Permitir Ficheros grandes – Upload Onwcloud

Hace poco me he montado un owncloud casero y me dió algunos problemas, a la hora de poder hacer upload de los ficheros con un tamaño grande, del orden de Gb.
Revisando información en castellano, no he encontrado referencias claras, por eso dejo aquí los cambios que he necesitado. Básicamente son 2…..

1.- Tamaño máximo de subida.

Estos parámetros se pueden cambiar en el php.ini de la maquina, pero no tendrán valor ya que son sobrescritos por el «.htaccess» del owncloud, por lo que se deben modificar en el directorio web del owncloud.

Ej. Para 2Gb

php_value upload_max_filesize 2G
php_value post_max_size 2G

2.- Tiempo máximo de ejecución. (Esta es la parte menos documentada.)

Además de esto, cuanto mayor es el fichero más tiempo de ejecución necesita el cgi para hacer el upload, por lo que debemos aumentar el tiempo de ejecución o obtendremos un «Internal server error«, ya que la subida se corta. Sigue subiendo pero ya no lo almacenamos en el fichero temporal, el cual deja de crecer llegado ese punto.
Esto se puede revisar viendo crecer el fichero en «/tmp» o donde se almacene.
Estos valor los he cambiado directamente en php.ini
Dejándolos en 1h (Por defecto los tenia en 60s):

max_execution_time = 3600
max_input_time = 3600

Con estos cambios tenemos la subida de ficheros grandes solucionada.
Además de esto, he cambiado la forma por defecto de loguear de ownclud.
En el fichero:

..../owncloud/config/config.php

Definimos:

  'log_type' => 'owncloud',
  'logfile' => '/var/log/owncloud.log',
  'loglevel' => '2',
  'logdateformat' => 'F d, Y H:i:s',

Nota: También se puede tirar contra syslog y por supuesto hay varios levels de logg, en la documentación esta indicado.

Temperatura – Raspberry

Siempre había tenido la «falsa» sensación de que la raspberry no debía calentarse mucho. Como siempre llaga la hora de despertar.
Tras varias tomas aleatorias ví que la temperatura era mas menos de unos 60ºC sin tener nada de carga de trabajo.

root@RASP1:~# /opt/vc/bin/vcgencmd measure_temp
temp=60.5'C

Así que para tener una opinión mas formada he decidido tomar un muestreo cada hora, durante una semana. Al final indicare como los he obtenido, aunque no tiene misterio.

Gráficas:
21 / 22 Agosto 2014

   
23 / 24 Agosto 2014

   
25 / 26 Agosto 2014

   
27 / 28 Agosto 2014

   
Se puede ver que la temperatura media es de unos 60ºC y que hay picos de las 10h a las 12h los cuales tienen su explicación… , ya que es el momento en que el sol incide sobre las raspberry por la ventana. Los días que recuerdo tapar la luz no existen estos picos.
Por otro lado he colocado un ventilador el cual puedo encender o parar con un interruptor.  Tras dejar un día completo el ventilador funcionando la caída de temperatura es muy alta…

29 / 30 Agosto 2014 ( Ventilador ON )

   
La caída es de unos 20ºC (33%) aproximadamente. Es así como debería estar siempre.
Con estas pruebas la opción mas evidente es dejar funcionando el ventilador pero tiene un problema…..
El «sonido» más bien «ruido«, es sumamente molesto…. Ahora estoy pensando en como aislar un poco la raspberry , para atenuar lo suficiente el ruido…. caja de cartón, corcho….. Ya iré probando.

Raspberry con Ventilador y disipadores.

Para tomar las medidas he usado los siguientes mini scripts, por llamarlos algo…

En el cron de root:

#Toma Datos Control Temperatura
00 * * * * /usr/local/scripts/control_temperatura/temperaturas.sh
15 00 * * * /usr/local/scripts/control_temperatura/genera_grafica.sh
30 00 * * * rm /usr/local/scripts/control_temperatura/datos_temp.txt

temperaturas.sh

#!/bin/bash
PATH_TRAB=/usr/local/scripts/control_temperatura
if [ ! -f $PATH_TRAB/datos_temp.txt ]; then
echo "#Hora Temperatura">>$PATH_TRAB/datos_temp.txt
fi
HORA=`date +%H`
TM=`/opt/vc/bin/vcgencmd measure_temp`
TEMPERATURA=`echo ${TM:5:-2}`
echo $HORA $TEMPERATURA>>$PATH_TRAB/datos_temp.txt

genera_grafica.sh

#!/bin/bash
PATH_TRAB=/usr/local/scripts/control_temperatura
NOMBRE=grafica_`date +%d_%m_%Y`.jpg
sed -i 's/00\ /24\ /g' $PATH_TRAB/datos_temp.txt
cat $PATH_TRAB/script_plot.sh |gnuplot > `echo $PATH_TRAB/$NOMBRE`

script_plot.sh

set terminal jpeg #Formato de salida
set title "Grafica Temperatura" #Titulo
set xlabel "HORA" #Etiqueta eje x
set ylabel "TEMPERATURA" #Etiqueta eje y
set yrange [0:100] #Rango eje y
#Dibujo de la gráfica (columnas 1 y 2) tipo de línea 4 y ancho de línea 3:
plot '/usr/local/scripts/control_temperatura/datos_temp.txt' using 1:2 with linespoints linetype 4 linewidth 3 title "Temp"

Cuando tenga la chapucilla para el ruido lo colgaré.

Apagado disco USB – RaspBerry

Publicación original: 19.07.2014

Tengo una raspberry conectada 24/7, en la cual tengo conectado un disco usb que uso muy poco (motivo por el que nunca se me había planteado la necesidad de poder «apagarlo» automáticamente). Hasta ahora montaba y desmontaba el disco según necesidades.

Es posible que para un proyecto futuro, me interese tener el/los disco/s montados siempre y que el SO los apague según el tiempo de inactividad.
Un compañero me comento el uso y me he puesto a mirar HDPARM

Nota:

Simplemente a modo de recordatorio, buscando info sobre el tema he visto que podemos saber si ha existido actividad en el disco consultando el fichero:

/sys/block/sda/stat

Cuando se realizan operaciones sobre el disco el valor número cambia.

cat /sys/block/sda/stat | tr -dc "[:digit:]"

HDPARM

Con mi disco he tenido unos problemas, que detallare al final. Aunque el estado «unknown» que se ve a continuación, esta relacionado con mis problemas.

Ver el estado del disco:

root@RASP1:~# hdparm -C /dev/sda1
/dev/sda1:
drive state is: unknown
root@RASP1:~#

Si todo funciona correctamente el estado debe ser «active/idle, standby»….

Ver el tiempo tras el que pasaremos a inactividad «spin-down«

root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 120

Este valor se debe entender del siguiente modo:

• SI Permitimos el Spin-Down: Entre 1 y 127
• NO Permitimos el Spin-Down: Entre 128 y 254
• El valor de 255 : Desactiva la gestión de energía avanzada del disco duro.

Cuando permitimos el spin-down, el tiempo en segundos, se obtiene multiplicando por 5 el valor dado, así un valor de 120, serán 120*5 segundos….. 10 minutos

Estableciendo el valor:

Para esto editamos el fichero de configuración de hdparm:

/etc/hdparm.conf

Y al final añadimos: (Este punto no he conseguido que funcione con mi disco)

/dev/DISCO {
  spindown_time = Valor_deseado}

Tras esto es suficiente con dejar el demonio corriendo:

/etc/init.d/hdparm restart

NOTA: Problemas con mi disco

Las pruebas las estoy haciendo con un disco WD:

root@RASP1:~# hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: WDC WD5000BEVT-11A03T0
Serial Number: WD-WX30A6957814
Firmware Revision: 01.01A01
...

En este disco no he podido definir el valor en el fichero de configuración, así como ver el estado del disco, ni forzar el «apagado» del disco

root@RASP1:~# hdparm -y /dev/sda
/dev/sda:
issuing standby command
HDIO_DRIVE_CMD(standby) failed: Invalid argument

Sin embargo el disco si para cuando establezco el valor via comando:

root@RASP1:~# hdparm -B 121 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0x79 (121)
HDIO_DRIVE_CMD failed: Invalid argument
APM_level = 121
root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 121
root@RASP1:~#
root@RASP1:~#
root@RASP1:~# hdparm -B 120 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0x78 (120)
HDIO_DRIVE_CMD failed: Invalid argument
APM_level = 120
root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 120

Este valor esta en uso hasta que el disco se desconecta de la corriente. Por lo que no es un problema para mi no poder, establecerlo de manera permanente.

Procesos en segundo plano – SIGHUP, NOHUP

Publicación original: 14.07.2014

Me parece interesante a modo de «chuleta» y/o recordatorio comentar un poco este tema…
Lo quiero separar en dos partes una sobre los procesos en segundo plano y otra sobre la señal SIGHUP.

• Procesos en segundo plano

Los procesos en segundo plano son aquellos que pese a estar en ejecución no tenemos la posibilidad de interactuar con ellos.

La manera de lanzar procesos en segundo plano es añadiendo al final & , de este modo el proceso quedará en ejecución pero liberará la shell, para poder seguir trabajando.

gandalf ~ # find / -name hola &
[1] 19968
gandalf ~ # ps -ef|grep find
...
[1]+  Hecho                   find / -name hola

Para poder interactuar con estos procesos necesitamos traerlos a primer plano y para realizar esta gestión tenemos los comandos jobs, bg y fg

Un ejemplo…. Lanzamos dos procesos en segundo plano:

gandalf ~ # while true; do echo "ab" > /dev/null; done &
[1] 20265
gandalf ~ # while true; do echo "a" > /dev/null; done &
[2] 20266

Visualizamos los procesos en segundo plano así como su estado:

gandalf ~ # jobs
[1]-  Ejecutando              while true; do
echo "ab" > /dev/null;
done &
[2]+  Ejecutando              while true; do
echo "a" > /dev/null;
done &

Traemos uno de los procesos a primer plano y lo detenemos con Ctrl+Z

gandalf ~ # fg %1while true; do
echo "ab" > /dev/null;
done
^Z
[1]+  Detenido                while true; do
echo "ab" > /dev/null;
done

Al listar los procesos en segundo plano tenemos uno detenido y uno en ejecución.

gandalf ~ # jobs
[1]+  Detenido                while true; do
echo "ab" > /dev/null;
done
[2]-  Ejecutando              while true; do
echo "a" > /dev/null;
done &

Volvemos a poner en ejecución en background el proceso que estaba detenido.

gandalf ~ # bg %1
[1]+ while true; do
echo "ab" > /dev/null;
done &
gandalf ~ # jobs
[1]-  Ejecutando              while true; do
echo "ab" > /dev/null;
done &
[2]+  Ejecutando              while true; do
echo "a" > /dev/null;
done &

También podemos matar un proceso en background determinado

kill %2

• SIGHUP / NOHUP

Cuando un proceso termina lanza una señal SIGHUP a los procesos que cuelgan de el, y estos reaccionan simplemente saliendo.
Esto es un problema cuando queremos dejar corriendo algún proceso en la shell en la que nos encontremos, ya que aun teniéndolos en background, al salir de la shell el proceso terminará.
Podemos evitar esto lanzado el proceso con NOHUP, lo cual hará que el proceso no «escuche» la señal SIGHUP de su proceso padre.
Para lanzar un proceso con NOHUP basta con (nohup «comando»), por ejemplo:

nohup ./script.sh arg1 arg2
nohup su - user -c "./script arg1 arg2"

Algo interesante, a tener en cuenta, es el tratamiento de la salida /entrada estandar, así como de la salida de error que hace nohup.

• Salida estandar –> Si no esta redirigida, se redirige a $HOME/nohup.out
• Entrada estandar –> SI no esta definida toma valor de «/dev/null»
• Salida de error –-> Si no está definida es redirigida a la salida estandar.

Referencia Indirecta - Bash

Este post es más una nota que un post como tal, por su extensión y sobre todo por su función.....

Hace un par de semanas necesité hacer uso del concepto de punteros en bash.
La verdad es que no se si lo había usado anteriormente, lo que si sé, es que no recordaba como hacerlo, de ahí esta nota.

El concepto se llama habitualmente referencia indirecta.

Simplemente pretendo dejar plasmada la sintaxis a modo de recordatorio, así que no me extenderé nada.....

Podemos referenciar variables de dos modos... directa o indirectamente.

Antes de BASH v.2
A="cadena resultante"
B="A"
-------------------------
echo $A
.......cadena resultante
-------------------------
echo $B
.......A
-------------------------
eval C=\$$B
echo $C
.......cadena resultante

Desde BASH v.2
A="cadena resultante"
B="A"
-------------------------
echo $A
.......cadena resultante
-------------------------
echo $B
.......A
-------------------------
echo ${!B}
.......cadena resultante

Podemos acceder al contenido de la variable A, haciendo uso de su propia referencia o de la referencia que contiene la variable B.

La referencia la obtuve del siguiente artículo.
Aquí un artículo donde se detalla perfectamente este concepto.

Gestión LVM - 2ª Parte

Hace ya bastante tiempo, escribía acerca de la monitorización de volúmenes lógicos (LVM), ademas de dar una pequeña introducción al concepto. Ahora por necesidades de trabajo he tenido que retomar el tema, esta vez para gestionarlos.

Por esto, voy a dejar reflejadas las notas básicas para la creación y gestión (Creación de VG, PV y LVM, aumentar tamaños, disminuirlos....)

CREACIÓN

--------------------------

==> Añadir disco a PV (PhisicalVolume)

Esto se realiza con el comando:

pvcreate /dev/sdb

Nota: Si añadimos un disco directamente a un VG, se crea el PV:

vgextend VGRaiz /dev/sdb

No physical volume label read from /dev/sdb

Physical volume "/dev/sdb" successfully created

Volume group "VGRaiz" successfully extended

==> Crear VG(VolumeGroup)

Los VG son equivalentes a los Disco Físicos.

vgcreate NombreVG /dev/sdb /dev/sda

==> Añadir PV a VG (VolumeGroup)

Esto se realiza con el comando:

vgextend VGRaiz /dev/sdb

No physical volume label read from /dev/sdb

Physical volume "/dev/sdb" successfully created

Volume group "VGRaiz" successfully extended

Nota: Podemos verificarlo con el comando: (Ampliado aquí)

lvm

lvm> pvscan

PV /dev/sda2 VG VGRaiz lvm2 [31,78 GB / 0 free]

PV /dev/sdb VG VGRaiz lvm2 [19,97 GB / 5,88 GB free]

Total: 2 [51,75 GB] / in use: 2 [51,75 GB] / in no VG: 0 [0 ]

lvm>

==> Crear LV (LogicalVolume)

Esto se realiza con los comandos:

1.- Crear el LV

lvcreate -L 20G NombreVG -n NombreLV

2.- Crear el sistema de ficheros.(Formato)

mkfs.ext3 /dev/NombreVG/NombreLV

3.- Añadir a fstab y montar.

Nota: Si es Swap mirar el final del post

REDIMESIÓN

--------------------------

==> Crecer LV

Esto se realiza con los comandos:

1.- Ampliar el LV

lvextend -L XXGB /dev/NombreVG/NombreLV

Todo el espacio libre:
lvextend -l +100%FREE /dev/NombreVG/NombreLV

Nota: Se puede definir en lugar del tamaño del LV el incremento que se desea aumentar

(-L +XXGB)

2.- Redimensionar el sistema de ficheros.(ext2/ext3)

Para redimensionar el sistema de ficheros no es necesario definir el tamaño si queremos ocupar el espacio disponible en el LV

resize2fs /dev/NombreVG/NombreLV

Nota: Si es Swap mirar el final del documento

==> Decrecer LV

Los pasos necesarios son los siguientes:

1.- Desmontar el filesistem que queramos decrementar

#umount /dev/NombreVG/NombreLV

2.- Decrementar el filesistem

resize2fs /dev/NombreVGNombreLV XXGB

3.- Decrementar el LV

lvreduce -L XXGB /dev/NombreVG/NombreLV

o

lvreduce -L -XXGB /dev/NombreVG/NombreLV

(Con "-XX" definimos cuanto queremos decrementar)

4.- Montar el filesistem que hemos redimensionado

mount /dev/NombreVG/NombreLV /PuntoMontaje

==> Borrar LV

Los pasos necesarios son:

1.- Desmontar el LV que queremos eliminar.

umount /dev/NombreVG/NombreLV

2.- Eliminar el LV

lvremove /dev/NombreVG/NombreLV

==> Acciones sobre Swap

Para redimensionar la swap realizamos las siguientes acciones:

1.- Paramos la Swap

swapoff -a

2.- Redimensionamos el LV como se ha definido en los pasos anteriores.

3.- Creamos la Swap con el tamaño correcto.

mkswap -c /dev/NombreVG/nombreLV

4.- Levantamos la swap

swapon -a