Directorio home de usuarios + nfs4: lentitud en el escritorio.

Una de las cosas que mas me gustan de Linux en un entorno de red es la capacidad de que los homes de los usuarios estén centralizados en un servidor de red común, de tal forma que siempre tenemos el mismo escritorio independientemente de la máquina usada. Esto facilita al usuario trabajar sin tener que andar subiendo ficheros a una nube o carpeta concreta de red, y a nosotros hacer copias de seguridad de sus datos y no preocuparnos de recuperar datos del usuario cuando falle físicamente el disco del equipo donde ha estado trabajando.

En nuestro caso siempre hemos usado NFS para montar estos homes, aunque hay mas alternativas. Nunca había habido problema pero cuando cambiamos hace unos años a usar Ubuntu 18 empezaron a aparecer problemas aleatorios de lentitud extrema en los escritorios/navegadores web. Una explicación común es que el aumento de complejidad de los navegadores en los últimos años (y eso es algo de lo que habrá que hablar algún día martillo en mano) los ha convertido en unos artefactos que con sus operaciones de entrada/salida acaban saturando el servidor NFS. Una pista en contra de esta hipótesis es que la lentitud va y viene sin correlación aparente con el número de usuarios instantáneos en la red del centro y que cuando una máquina va lenta, la de al lado no tiene por qué hacer lo mismo. Tenía que haber alguna explicación adicional.

Después de muchas pruebas hemos establecido que cambiar el sistema de montaje de los homes de los clientes de nfs4 a nfs3 mejora enormemente el problema, haciéndolo desaparecer en muchos casos. Vamos a ver las pruebas a realizar cuando tenemos un escritorio/navegador ralentizado para determinar si este cambio en el nfs solucionaría el problema.

Las pruebas que podemos realizar son las siguientes:

• Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer el comando "time su <usuario>", siendo "usuario" un usuario que monta su home por NFS, claro está. Hacer lo mismo en un equipo no afectado por el problema. Si en el primero tarda 5 o mas veces que el segundo es un síntoma de que está afectado.
• Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer "wget https://speed.hetzner.de/1GB.bin". Hacer lo mismo en un equipo no afectado por el problema. Es un fichero de prueba de 1Gb para hacer tests de velocidad desde consola. Si la velocidad es similar en ambos puestos podemos descartar que sea un problema de red (bucles de red, problemas de cableado, de switchs, de salida a Internet) y centrarnos en que es un problema de NFS.
• Entrar por ssh como root a un puesto donde el escritorio vaya lento y mirar en el syslog buscando errores como:

  NFS: nfs4_reclaim_open_state: Lock reclaim failed!
  NFS: nfs4_reclaim_open_state: unhandled error -10026
  nfs4_reclaim_open_state: 3 callbacks suppressed
      

  Estos errores son síntomas de bloqueos y otros problemas en el montaje NFS.
• Entrar en el servidor NFS y testear la carga con los comandos:

  # atop
  # iotop
  # nfsstat
    

  Buscando sobrecargas en el disco, red o en los procesos nfs.
• Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer

  # nfsiostat
    

  Comparar el resultado con un equipo no afectado por el problema.

Después de todas estas pruebas, si sospechamos que las causas de la lentitud están relacionadas con el servidor NFS, el siguiente paso es verificar que tipo de montaje usamos en nuestros puestos. Para ello entramos por ssh como root en un equipo de usario y hacemos:

# automount -m

global options: none configured

  Mount point: /home

  source(s):

   type: ldap
   map: ldap:ou=auto.home,ou=Automount,dc=instituto,dc=extremadura,dc=es
   ....
   ....
   * | -fstype=nfs4,rw,hard,intr,nodev,nosuid,nolock,rsize=16384,wsize=16384 servidor:/&

La última línea nos dice que el montaje del home esta siendo realizado mediante nfs4. No tiene porque ser igual a la indicada, pero el "nfs4" es revelador. La idea es cambiarla por:

   * | -fstype=nfs,rw,fg,hard,intr,nodev,nosuid,async,ac,vers=3,fsc servidor:/home/&

que cambia el montaje del home para que se haga usando nfs3. Esta línea si que debemos ponerla de forma literal, tal cual aparece aquí.

El lugar donde se hace este cambio dependerá de donde configuremos el montaje en nuestro entorno. Para el caso de nuestros centros esto se hace en el directorio ldap, al que accedemos mediante phpldapadmin en el nodo:

cn=/,ou=auto.home,ou=Automount,dc=instituto,dc=extremadura,dc=es

Una vez allí localizamos el atributo "automountInformation", hacemos una copia de su contenido por si las moscas y lo sustitumos por:

* | -fstype=nfs,rw,fg,hard,intr,nodev,nosuid,async,ac,vers=3,fsc servidor:/home/&

Después de esto recargamos el servicio nfs en el servidor principal:

/etc/init.d/nfs-kernel-server reload

Y por último reiniciamos los clientes, dejando que trabajen durante varios días a ver si desaparecen los problemas. En bastantes casos con este sencillo cambio ha sido suficiente.

Demoras en el arranque de los PC "infolab"

Ya contamos como configurar como puestos multiseat los infolabs HP ProDesk 600 G1 SFF que tenemos, permitiendo que un mismo PC fuese usado por 2 usuarios a la vez de forma concurrente.

Había venido observando que el arranque de un PC infolab con multiseat era bastante mas lento (un minuto o más) que el de un infolab normal. En un primer momento lo achaqué a su condición de multiseat: al tener dos escritorios concurrentes quizá el arranque tarda más mientras preparaba el entorno. Pero como no estaba muy convencido he estado investigando.

Lo primero es medir los tiempos de arranque con systemd-analyze. Con:

# systemd-analyze blame

Nos sale una lista decreciente de tiempos y procesos, llamándome la atención esto:

54.4s dev-sda5.device

Comparando con otro infolab sin multiseat:

7.471s dev-sda5.device

Buscando en Internet veo que dev-sdaX.device no es nada en concreto, no se corresponde con ningún servicio y no hay manera de sacar información de ahí. Analizando con "systemd-analyze plot" y "systemd-analyze critical-chain" no saco nada más en claro.

Bueno, pues otra manera mas detallada de analizar el arranque es utilizar systemd-bootchart, que guarda una imagen SVG en /var/run con los tiempos y procesos de arranque más detallada que la de "systemd-analyze plot".

Analilzando veo que el proceso mas destacado es nvidia-smi lanzado desde systemd-udevd, el cual tarda 14s en ejecutarse. Si lo hago en un equipo sin multiseat veo que tarda menos de medio segundo.

Pensando entre las diferencias que hay entre infolabs con y sin multiseat recuerdo el tema de las tarjetas VGA. Un infolab trae 2 tarjetas VGA de serie:

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B [GeForce GT 730] [10de:1287] (rev a1)

En el caso de un equipo multiseat ambas VGA están activas (ya que hacen falta para los 2 monitores). En un equipo normal tengo la tarjeta VGA Intel (la de la placa base) desactivada en la BIOS, ya que no me hace falta y la desactivo para evitar problemas.

Como ultima comprobación, mirando el syslog de arranque con dmesg encuentro que, cuando hay retraso, este mensaje aparece en el log:

watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [nvidia-smi:618]

Deduzco que es casi seguro que la combinación del programa nvidia-smi (que viene con el driver propietario nvidia) y la tarjeta VGA intel de la placa base son la causa del problema.

Consideremos estas pruebas y limitaciones:

• No puedo prescindir de los drivers nvidia, ya que con nouveau no funciona el multiseat.
• No puedo desactivar la tarjeta intel en la BIOS, ya que la necesito para seat-1 del multiseat.
• He probado con distintos kernel 4.x y 5.x por si fuera un fallo del driver. No se arregla con ninguno.
• He actualizado el driver propietario a la ultimísima versión (usando el PPA). No se arregla.

Cuando no se te ocurre nada nuevo es el momento de buscar en Internet. Buscando por el texto del error mostrado en el syslog encuentro:

• Solución 1: Añadir nomodeset como parámetro de arranque del kernel en el grub. Se arregla el problema, pero no funciona el multiseat. El seat-1 no se levanta.
• Solución 2: en el fichero /lib/udev/rules.d/71-nvidia.rules comentar la línea:
  

  ACTION=="add" DEVPATH=="/module/nvidia" SUBSYSTEM=="module" RUN+="/usr/bin/nvidia-smi"
  

Pues está última propuesta funciona. Comentando esa línea impedimos que nvidia-smi (el causante del problema) se ejecute en el arranque del sistema, al iniciar la tarjeta nvidia. Parece temerario pero resulta que al final que el arranque se acelera (dev-sda5.device dura unos segundos en lugar de casi un minuto) y el multiseat funciona. Hablando en plata: la ejecución inicial de nvidia-smi es prescindible.

Como colofón podemos decir que esto no es es solamente aplicable cuando hay multiseat (que es como me ha salpicado a mí): siempre que haya una demora en el arranque producido por un conflicto entre nvidia-smi y una tarjeta no nvidia en la placa madre la solución será comentar esta línea que ejecuta en el inicio nvidia-smi. Tomemos nota para el futuro.

---

Qué bonitos los robots de Boston Dynamics, no entiendo como a mi compañera Marisa le dan repelús:

Lentitud de páginas web multimedia en thinclients de LTSP Ubuntu 18.

Me ha llegado una incidencia sobre la lentitud de un aula de thinclients sobre LTSP en Ubuntu 18 al abrir páginas web. Tras hacer pruebas in situ pude comprobar que al abrir varias páginas con 10 o mas thincliens encendidos todo se hacía enormemente lento, incluido el servidor LTSP, de tal manera que era imposible trabajar.

Descartado un problema de red me centro en ver que páginas usan: son unas páginas de idiomas que tienen mucho Flash (Odín maldiga al Flash) y que además abren muchas pestañas de Firefox. Haciendo un "ps aux | grep firefox" veo que hay una burrada de instancias de Firefox abiertas (mas de 40 procesos) y que eso puede provocar la fastidiosa lentitud de alguna manera que se me escapa.

En las últimas versiones de Firefox se ha implementado una feature llamada Electrolysis que, al igual que tiene hace tiempo Chrome, implica que Firefox abra procesos a tutiplén (uno o más por cada pestaña) para mejorar el rendimiento. Eso está muy bien para un entorno monousuario, pero en un entorno donde hay 10 o 12 usuarios en la misma máquina abriendo pestañas puede llevar las cosas al límite, especialmente en nuestros servidores LTSP con CPU Intel Core2 Quad de casi 10 años de antigüedad.

¿Se puede controlar este desmadre procesil? Pues en parte si, tocando varias configuraciones. Para hacerlo automático y que se aplique de forma obligatoria a todos los usuarios del PC (evitando tener que tocarlo perfil a perfil) lo mejor es usar el fichero syspref.js global de /etc/firefox:

# cat /etc/firefox/syspref.js
...
...
...
//Limitar el nmero de procesos firefox. Thinclients.
pref("browser.tabs.remote.autostart", false, locked);
pref("extensions.e10sMultiBlockedByAddons", false, locked); 
pref("dom.ipc.processCount", 1, locked); 

y distribuir dicho fichero mediante puppet a las máquinas que lo necesiten.

Con esto el número de instancias de Firefox se queda en 1-2 para cada usuario y la cosa se hace sensiblemente mas manejable: antes iba como el culo y ahora va casi medio bien.

Otra opción podría ser ejecutar Firefox de forma local en los thinclients, con sus propios recursos. Eso se hace lanzándolo así:

# ltsp-localapps firefox

El problema de esto es que:

• Se ejecuta el Firefox y el Flash de 32bits contenido en la imagen de los thinclients, sensiblemente mas antiguo que el del servidor LTSP. Las imágenes de los thinclients están basadas en Ubuntu 14.
• Al ejecutarse con el procesador y memoria de los thinclients tarda en arrancar y puede ir bastante ralentizado (suelen ser Pentiums IV con 512Mb de RAM). La ventaja es que no satura el servidor ni los thinclients ajenos.

Si aún así queremos hacerlo funcionar la forma mas adecuada es poner un script en los servidores LTSP que detecte si estamos en un thinclient o el servidor (examinando el contenido de la variable $LTSP_CLIENT) para lanzar el Firefox de una manera u otra:

# cat /usr/local/bin/firefox
#!/bin/bash
if [ ! -z "$LTSP_CLIENT" ]; then
       ltsp-localapps firefox
else
       /usr/lib/firefox/firefox "$@"
fi
exit 0
# chmod +x /usr/local/bin/firefox

Al estar /usr/local/bin por delante de cualquier otro directorio en $PATH siempre se ejecutará primero el script al llamar a "firefox".

Con esto conseguimos que la cosa tire mejor en tanto en cuanto Flash no sea purgado de la faz de la Tierra.

Software Reporter Tool y ralentización de los Windows.

Esta va de Windows. Después de hacer este curso un downgrade de Windows 10 a Windows 7 en varios equipos usados en los ciclos de FP en el centro porque entre actualizaciones, cortanas y demás enredos se hacían inmanejables ha habido un período de calma hasta que me avisaron que algunos empezaban a ir muy lentos de forma injustificada.

Tras mirar con el explorador de procesos no vi ningún proceso desbocado, pero si me chocaba que el procesador estaba siempre por encima del 60%, aún cuando no se hiciese nada. Para dilucidar que pasa en estos casos lo mejor es usar el programa "Process Explorer", que muestra mucha mas información que el explorador de procesos tradicional del Windows.

Ahora si pude ver que había un proceso (antes oculto no se por qué motivo) llamado "Software Reporter Tool" que era el responsable del alto uso de la CPU. Este programa es algo que viene con el Google Chrome y que básicamente no hace nada que no sea hacer la puñeta. Se instala en cada perfil de usuario en la ruta "c:\users\*usuario*\AppData\Local\Google\Chrome\User Data\SwReporter\..." y se arranca cuando buenamente le parece para hacer sus maldades.

No se puede desinstalar pero si borrar, aunque comentan que cuando se actualice Chrome seguramente volverá a aparecer. De momento lo he limpiado en todos los pc ejecutando:

cd c:\users
for /d /r . %d in (SwReporter) do @if exist "%d" rd /s/q "%d"

Y de repente los pc afectados han revivido. Tendremos que estar al acecho para cuando vuelva a aparecer.