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: