Bienvenido a un nuevo episodio del podcast de Sergio. Pero antes de empezar, una cosita importante. Tras algunos avisos de oyentes sobre el volumen, me di cuenta de que los últimos episodios sonaban bastante más bajos de lo normal. Era un fallo mío en el montaje del audio. Así que pido disculpas. Ya he regenerado los dos episodios anteriores con el volumen corregido, y a partir de ahora espero tenerlo bien solucionado. Gracias por avisar, de verdad: se agradece un montón.

Y dicho esto, vamos a lo de hoy, que es una buena batallita. La historia de cómo una actualización de rutina tumbó mi servidor durante toda una noche... y de cómo, al día siguiente, la propia herramienta que tengo para que me avise de los problemas se convirtió en el problema. Dos incidencias encadenadas. Vamos allá.

Pongámonos en situación. Tengo un Mac mini, debajo de la mesa, haciendo de servidor las veinticuatro horas del día. Sirve mi web, las videollamadas, el aula de Moodle, el blog... todo desde casa. Y lleva meses funcionando como un reloj.

Una noche, antes de irme a dormir, lancé una actualización del sistema. Pura rutina. Se instaló, reinició, y yo a la cama tan tranquilo. A la mañana siguiente, el móvil echaba humo. El sistema de avisos me había mandado una colección de alertas a cuál más alarmante. Que si el contenido de una web era incorrecto. Que si faltaban cabeceras de seguridad. Que si la web no respondía.

El primer instinto, reconozcámoslo, es pensar lo peor: me han hackeado, se ha caído algo gordo. Pero había un detalle que no encajaba. Entre los avisos, uno decía que el código de respuesta era cero, cero, cero. Y eso es muy revelador. Cuando una web te da un error cuatrocientos cuatro, es que la página no existe. Un quinientos, que el servidor ha reventado. Pero un cero, cero, cero, significa que no hubo ni conexión. Nada. El servidor, sencillamente, no estaba ahí. Y eso no huele a hackeo. Huele a que algo, físicamente, no estaba encendido.

¿Y dónde estaba el servidor? Pues dormido. Literalmente. Al mirar los registros de energía del Mac, descubrí que se había pasado la noche entera durmiéndose y despertándose. Casi cien veces. Cada poco rato entraba en modo de bajo consumo, se desconectaba de la red, y al ratito volvía. Un servidor con narcolepsia.

¿La causa? La actualización, que parecía inofensiva, había reseteado la configuración de energía a los valores de fábrica. Y un Mac de fábrica viene configurado para dormir, porque se asume que es el portátil de alguien, no un servidor que tiene que estar despierto siempre. La solución fue blindarlo para que no se durmiera jamás, y de forma que aguantara los próximos reinicios. Servidor despierto otra vez. Crisis número uno, resuelta. O eso creía yo.

Ah, y un apunte que me hizo gracia: ¿por qué no me avisó nadie de madrugada? Pues porque el propio sistema que vigila corre en ese mismo Mac. Y una máquina dormida no ejecuta nada ni tiene red. O sea, el vigilante dormía con el servidor. Quédate con esta idea del vigilante que falla, porque va a volver.

Al día siguiente, cuando pensaba que todo estaba en orden, nuevo aviso: la CPU caliente. Algo llevaba más de treinta horas clavado al cien por cien de un núcleo. Treinta horas quemando el procesador a tope. Fui a ver qué proceso era el responsable, esperando encontrar la web, o la base de datos, o algo importante.

Y aquí viene la ironía. No era nada de eso. Era el proceso de la herramienta que uso para que me avisen de los problemas. El plugin que me manda las alertas a Telegram. El vigilante. Justo el que debía protegerme se había convertido en el incendio.

¿Y por qué se desbocó? Por la incidencia del día anterior. Ese plugin pregunta constantemente al servidor de Telegram si hay mensajes nuevos. Pregunta, espera, vuelve a preguntar. Con la red inestable de la noche del sueño, esas preguntas empezaron a fallar, y el plugin entró en un bucle de reintentos sin freno que se comió un núcleo entero.

Pero lo mejor, lo más bonito de todo, es lo siguiente. Ese plugin tiene un mecanismo de seguridad pensado justo para esto. Un vigilante interno que, cada pocos segundos, comprueba si el proceso se ha quedado huérfano y, si es así, se apaga solo, limpiamente. Un diseño impecable.

Salvo por un detalle. Ese vigilante interno necesita que la CPU le dé un respiro para ejecutarse... y la CPU estaba al cien por cien, atrapada en el bucle. Así que la comprobación nunca llegó a hacerse. El mecanismo de autoprotección quedó anulado justo por el fallo que tenía que resolver. El vigilante, otra vez, secuestrado por el mismo incendio que debía apagar.

La solución, una vez localizado, fue de lo más simple: matar el proceso a la fuerza. Se relanzó él solo, limpio, y la CPU pasó del cien por cien a prácticamente cero. Reconecté Telegram, mandé un mensaje de prueba, lo recibí. Todo en orden.

Y aquí podría acabar, pero hay un epílogo que me parece la mejor parte. Antes de salir corriendo a reportar el fallo, hice lo que debería ser el primer reflejo de todos: comprobar si ya estaba reportado. Y vaya si lo estaba. El plugin es el oficial de Anthropic, y había más de una docena de avisos abiertos describiendo exactamente lo mismo que yo acababa de vivir.

Primera lección: cuando te encuentras un fallo así, lo primero es buscar duplicados. Abrir el aviso número doce, idéntico a los once anteriores, no ayuda a nadie. Solo añade ruido al que tiene que arreglarlo. Pero una cosa es no duplicar, y otra es no aportar. En lugar de abrir un hilo nuevo, comenté en uno de los existentes con tres datos que no estaban en la conversación. Que el fallo pasaba también en los Mac con chip de Apple, no solo en los antiguos. Que el detonante, en mi caso, no era el que ellos pensaban, sino la pérdida de red. Y el detalle más fino: por qué ese vigilante interno nunca saltaba.

Y esa es la moraleja con la que te dejo. Un buen reporte de un fallo no es decir, he encontrado un bug. Eso ya lo sabían once personas antes que tú. Un buen reporte es decir: aquí tenéis un dato nuevo para reproducirlo o arreglarlo. Contribuir a algo que ya existe, aunque sea con una sola observación que falte, vale más que empezar de cero por tu cuenta.

Gracias por escuchar el podcast de Sergio. Y acuérdate: cuando algo raro pase, antes de asustarte, pregúntate si lo que ves es la causa... o la consecuencia de algo que pasó antes. Nos escuchamos en el próximo. Cuídate.