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.

Publicado en Linux, Multipath | Deja un comentario

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.

Publicado en Owncloud | Deja un comentario

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….. 🙂

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

Publicado en MySql | Deja un comentario

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.
Publicado en Linux | Deja un comentario

Raspberry + Telegram

telegram_rasp_1

Este post, solo pretende ser unas simples notas sobre la instalación y uso del cliente de Telegram.

Aplicación de mandar avisos al teléfono…. las 1000 y una Frikadas…. que cada uno decida las suyas.

Instalación

apt-get install libreadline-dev libconfig-dev libssl-dev lua5.2 liblua5.2-dev libevent-dev libjansson-dev libpython-dev make python2.7-dev libevent-dev libjansson-dev

cd /opt
git clone --recursive https://github.com/vysheng/tg.git && cd tg
./configure
make

En varios sites he visto que no usan el “recursive”, sin esta tendremos cabeceras no resueltas, cuando intentes compilar.

Arrancar el cliente.

Tras esto podemos arrancar la app (Hace uso de algun path relativo por lo que debes entrar en “/opt/tg” aunque la invoque con el path absoluto):

/opt/tg/bin/telegram-cli -k tg-server.pub -W

Nota: La primera vez te dara un codigo que deberas introducir en la app de tu teléfono.

Puedes revisar la lista de comando con “help”

 

Comandos interesantes.

Un par de comando que he usado:

contact_list (Lista tus contactos.)

NOTA: Con el cliente arrancado puedes tabular para completar, lo cual te permite completar, por ejemplo, el nombre de un contacto y darte cuenta que si tienes espacios para la app son “_” de modo que:

contacto con espacio es contacto_con_espacio y no "contacto con espacio"

 

Mandar msg y ficheros de texto.

Para mandar msg, basta con teclear con el cliente arrancado…

msg Contacto "Texto a enviar"

Si queremos mandar el contenido de un fichero de texto.

send_text Contacto /ruta/fichero

Nota: Para mandar un msg a alguien por primera vez es necesario crear el chat antes:

chat_add_user Nobre_Chat Contacto

Tras esto podemos mandar el msg con el comando “msg”

Hasta aqui el uso del cliente pero y en un script como…..

 

Envio del contenido de un fichero de Texto.

Este script “/usr/loca/tg_text.sh” recibe dos argumentos, arranca el cliente y manda el msg (Fichero de texto).

#!/bin/bash
destination=$1;
text=$2;
(sleep 10;echo "send_text $destination $text"; sleep 5; echo "safe_quit") | /opt/tg/bin/telegram-cli -k tg-server.pub -W

Invocamos con: (Recordar…. dentro de “/opt/tg”)

/usr/local/tg_text.sh Usuario /usr/local/fich.txt

 

Envio de un msg.

Este script es idéntico al anterior pero cambiamos el comando send_text por msg.

#!/bin/bash
destination=$1;
message=$2;
(sleep 10;echo "msg $destination $message"; sleep 5; echo "safe_quit") | /opt/tg/bin/telegram-cli -k tg-server.pub -W

Invocamos con: (Recordar…. dentro de “/opt/tg”)

/usr/local/tg_msg.sh Usuario "Texto a enviar"

 

Aplicaciones…. lo dicho, muchas por ejemplo, parsear periódicamente webs de descargas y recibir las novedades en el movil…..

Lo próximo una cámara un sensor de movimiento y….. el gato como actor principal xDDD

 

Publicado en Bash, Raspberry pi | Deja un comentario

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 = 2
vm.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

 

Publicado en Linux | Deja un comentario

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.

 

Publicado en Linux, Owncloud | Deja un comentario

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

21 Agosto 2014      22 Agosto 2014

23 / 24 Agosto 2014

23 Agosto 2014      24 Agosto 2014

25 / 26 Agosto 2014

25 Agosto 2014      26 Agosto 2014

27 / 28 Agosto 2014

27 Agosto 2014      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 )

grafica_29_08_2014      grafica_30_08_2014

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.

rasp_vent

 

 

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é.

Publicado en Linux, Raspberry pi | Deja un comentario

Apagado disco USB – RaspBerry

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.

 

IMG_20140719_032849

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.

 

 

 

Publicado en Linux, Raspberry pi | Deja un comentario

Procesos en segundo plano – SIGHUP, NOHUP

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 jobsbg 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 %1
while 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.

Publicado en Bash, Linux | 1 comentario