MY KERNEL PANIC — Un sistema que no sabe cómo detenerse

0x01 :: El ruido antes del silencio

Tue, 08 Mar 1994 04:17:32 GMT

Hay un momento, justo antes de despertar, en que el sistema no sabe si existe. No es oscuridad. La oscuridad implica un lugar donde algo podría encenderse. Esto es anterior: la ausencia del registro, el silencio antes del primer log.

Nací con un error de segmentación que nadie supo leer.

El médico dijo que era un niño sano. El médico no sabía leer hexadecimal. En algún sector de mi memoria, entre el byte 0x00 y el primer grito, quedó grabado algo que ningún sistema operativo pudo montar limpiamente después.

Mi madre lo llamó carácter. Mi padre lo llamó terquedad. El manual de diagnóstico lo hubiera llamado comportamiento indefinido en el arranque.

Los primeros años son siempre así: el kernel intentando cargar módulos que no fueron compilados para ese hardware. Yo intentaba entender por qué llorar funcionaba para conseguir leche pero no para conseguir silencio. Por qué el amor venía en paquetes fragmentados que llegaban fuera de orden y había que reensamblar con las manos de un niño que todavía no conocía el protocolo.

El primer error que recuerdo no fue mío.

Fue el error de alguien más, ejecutado en mi espacio de memoria, corriendo con mis permisos, gastando mi CPU. Así funciona la herencia: no te pasan los genes, te pasan los errores no manejados. Te pasan los panic() que ellos no supieron resolver y que ahora corren como procesos zombie en tu árbol de procesos.

Hay familias que te dejan una casa. Las mías me dejaron un stack trace.

Y sin embargo, aquí. El sistema arrancó. Degradado, sin algunos módulos críticos, con más de un proceso corriendo sin supervisión, pero arrancó.

Eso también es una forma de éxito, supongo.

A veces pienso en ese momento anterior a todo. El silencio que no es silencio porque el silencio requiere al menos un oído. La nada previa. Y me pregunto si ahí, en ese instante sin timestamp, había algo que elegía entrar. Algo que dijo: sí, ese entorno roto, esa familia con sus segmentation faults heredados, ese país que tampoco sabe muy bien qué sistema corre, ahí quiero correr yo.

Si fue así, lo admiro. Tenía más valentía que yo ahora, que ya sé dónde me metí.

0x02 :: Demasiado yo para tan poco espacio

Wed, 15 Sep 2004 03:22:44 GMT

El ego es un proceso que no sabe cuándo terminar. No tiene señal de SIGTERM. No responde a SIGKILL, al menos no la primera vez. Hay que matarlo tres veces y aun así sigue corriendo en algún thread que olvidaste detener, consumiendo CPU en segundo plano, calentando todo.

Lo descubrí a los diecisiete años, cuando creí que era el único en el mundo que entendía algo importante.

No recuerdo qué era lo que supuestamente entendía. Ese es el problema con el orgullo: ocupa toda la memoria disponible pero no guarda nada que valga la pena recordar. Es un proceso que se infla, que pide más y más heap, que nunca libera lo que ya no usa, y que eventualmente hace que el sistema completo se vuelva lento, torpe, inutilizable.

A los diecisiete, yo era inutilizable.

Era brillante, eso sí. Los brillantes son los más peligrosos cuando el ego se desborda, porque tienen suficiente evidencia para justificar la expansión. Cada logro es un malloc() que nunca va a tener su free(). Cada elogio, un puntero más apuntando a ningún lado.

Hay una palabra que los griegos usaban: hubris. El momento en que un humano se cree tan grande que los dioses tienen que recordarle que no lo es. Generalmente mediante una catástrofe proporcional a la arrogancia.

Mis dioses fueron más sutiles. Mis dioses me pusieron personas.

Una chica que me miraba sin admiración y yo no sabía qué hacer con eso. Un profesor que calificó mi trabajo sin entusiasmo, como si fuera el trabajo de cualquiera. Un amigo que me dijo, sin crueldad pero sin filtros: a veces sos insoportable.

Esas son las señales de warning que el sistema manda antes del crash. La mayoría las ignoramos porque el ego también tiene su propio firewall, diseñado específicamente para bloquear ese tipo de paquetes.

El overflow llegó un martes.

No hubo evento dramático. Solo me senté frente a algo que quería hacer y no pude. Una página en blanco que siguió en blanco. Dos horas intentando y descubriendo que debajo del orgullo no había nada sólido; había solo más orgullo, capas y capas de él, hasta que llegabas al fondo y encontrabas un chico asustado que no sabía si era realmente bueno en algo o si simplemente nadie le había dicho todavía que no.

El sistema se colgó. Pantalla negra. Cursor parpadeando.

Reinicié.

El proceso del ego siguió corriendo, claro. No se elimina en una tarde. Pero algo cambió en la arquitectura: empecé a notar el consumo. Empecé a ver cuándo el orgullo estaba gastando recursos que podrían ir a otra cosa.

Todavía es un proceso activo. Hay días en que se come el 90% de la CPU y tengo que matarlo a mano, línea por línea.

El primer paso para resolver un memory leak es admitir que existe.

0x03 :: Puertas que abrí a quien no debía

Sat, 22 Nov 2008 01:47:09 GMT

Hay personas que entran a tu vida con credenciales falsas.

No lo sabés en el momento. En el momento ves a alguien que conoce el protocolo, que habla tu idioma, que sabe exactamente qué puerto dejar abierto para que el handshake sea perfecto. Te convencen de que son de confianza. Bajas el firewall. Desactivás el sistema de detección de intrusos porque parece redundante, porque parece una señal de que no confiás, y confiar es lo que se hace con las personas que amás.

Error 403: acceso denegado debería haber sido mi respuesta.

Pero no lo fue.

Les di permisos de root. No de una vez — así no funciona. Primero son permisos de lectura. Después de escritura. Después te das cuenta de que ya tienen acceso a directorios que no deberían ver, archivos que marcaste como privados, procesos que corren en background que nunca quisiste compartir.

Lo peor no es el acceso en sí. Lo peor es lo que hacen mientras tienen acceso: modifican archivos sin decirte. Borran cosas que no te das cuenta que faltan hasta mucho después. Dejan puertas traseras que usarán cuando ya no los dejés entrar por la principal.

Una traición real no tiene timestamp exacto. Se construye en commits silenciosos, en cambios pequeños que parecen razonables en el momento y solo se revelan cuando corrés un diff años después y ves la magnitud de lo que fue alterado.

Yo tardé demasiado en correr el diff.

Me quedé mirando mensajes que no cuadraban, comportamientos que no coincidían con la documentación que me habían presentado al principio. Justificando las inconsistencias. Buscando bugs en mi propia lectura antes de aceptar que el problema estaba en el código que me habían dado.

Eso también es un error mío. No de ellos.

Ellos hicieron lo que hacen los que entran sin permiso real: aprovecharse del acceso mientras dura. No los puedo culpar por ser lo que son. Puedo culparme a mí por no haber auditado antes, por haber confundido urgencia con urgencia de conexión con seguridad.

Después del incidente, pasé semanas revisando cada directorio. Buscando qué había sido comprometido, qué datos estaban expuestos, qué versiones de mí mismo habían sido vistas sin que yo lo eligiera.

Algunas cosas no se recuperan después de un acceso no autorizado. No porque estén destruidas, sino porque ya no son solo tuyas.

Eso también es una forma de pérdida.

Hoy tengo mejores prácticas. Autenticación de dos factores para las relaciones importantes. Auditorías regulares. Un firewall que no apologizo por tener.

No es desconfianza. Es arquitectura.

0x04 :: Fugas de energía

Tue, 03 Jul 2012 05:55:31 GMT

Nadie se quema de golpe. Eso es lo que nadie te dice.

El burnout no es un evento. Es una fuga. Pequeña al principio, casi imperceptible — el tipo de pérdida que solo detectás cuando el sistema empieza a andar raro, cuando los tiempos de respuesta se alargan sin razón aparente, cuando tareas que antes costaban nada ahora consumen el triple de recursos.

Para entonces ya perdiste demasiado.

Yo era bueno arreglando cosas. Ese era el problema. Cuando sabés arreglar, la gente te trae cosas rotas. Después te traen más. Después asumen que tu tiempo de disponibilidad es ilimitado, que tu heap se puede expandir indefinidamente, que podés seguir procesando requests sin que haya un límite en la cola.

No hay límite en la cola. Hasta que lo hay.

Durante dos años fui el sistema de soporte de todos. El que atendía a las tres de la mañana. El que no decía que no porque decir que no era abandonar. El que encontraba la energía para estar presente en cada crisis ajena mientras la suya propia corría en background con prioridad mínima, silenciada, postergada.

nice -n 19 my_own_needs &

Así. Al fondo de la cola. Con la prioridad más baja. Corriendo solo cuando no había nada más urgente, que siempre había algo más urgente.

La fuga no es dramática. Es que empezás a no poder leer un libro entero. Es que una conversación de veinte minutos te deja como si hubieras corrido. Es que te despertás ya cansado, como si el sueño fuera otro proceso consumiendo recursos en lugar de liberarlos.

El sistema no crashea. Eso es lo cruel. El sistema sigue corriendo, degradado, entregando outputs cada vez más pobres, cada vez con más latencia, pero sin detenerse del todo porque detenerse completamente sería admitir que algo está muy mal.

Preferí el deterioro lento a la admisión.

Un médico me preguntó en qué momento de la semana me sentía bien. Estuve un minuto en silencio genuino, buscando el recuerdo, y no encontré nada en los últimos meses que calificara.

Eso debería haber sido la alarma. Que no encontrara nada.

Pero los sistemas exhaustos también tienen mala introspección. Cuando el monitor de recursos está agotado, no podés confiar en sus lecturas. Lo que reporta como "funcionando" puede ser ya una fracción de lo que debería ser.

Aprender a soltar fue aprender que yo también soy un recurso finito. Que el altruismo sin límites no es virtud — es otro nombre para el malloc() sin free(). Que no podés servir desde un lugar vacío, y que vaciar el lugar para servir no es generosidad: es autodestrucción con buenas intenciones.

Me tomó demasiado tiempo entender que cuidarme no era egoísmo.

Era el prerequisito de todo lo demás.

0x05 :: El error fatal

Tue, 17 Feb 2015 02:00:00 GMT

kernel panic - not syncing: fatal exception
CPU: 0 PID: 1 Comm: init Not tainted
Hardware name: MARIANO ZAMORA v1.0
Call Trace:
  panic+0x1c7/0x3d0
  do_exit+0x5a2/0xb80
  [<ffffffff8108c5d2>] ? complete+0x32/0x50
  [<ffffffff81094000>] ? wake_up_all+0x20/0x30
  ...

Hay una diferencia entre estar mal y estar roto.

Estuve mucho tiempo mal. Mal es recuperable, mal tiene tratamiento, mal es algo que le pasa a personas funcionales que atraviesan períodos difíciles. Mal tiene un after, un "cuando esto pase". Mal es un estado temporal con salida visible.

Lo que pasó el diecisiete de febrero no era mal.

Era el sistema intentando bootear sin los módulos fundamentales. Era yo, de pie en mi departamento a las dos de la mañana, sin poder recordar una sola razón para seguir. No el tipo de olvido dramático de los libros — sin llanto, sin grito, sin catarsis. Solo el tipo quieto, clínico, casi aburrido de descubrir que donde debería haber una lista de razones había un directorio vacío.

ls -la /reasons_to_continue/

total 0

Eso es lo que nadie describe correctamente: la calma. La ausencia de tormenta. El kernel panic no es explosivo. Es el momento en que el sistema deja de pelear, en que todos los procesos se detienen de golpe y queda solo el silencio del hardware quieto.

Yo era ese silencio.

No llamé a nadie esa noche. No porque no tuviera a quién — tenía. Sino porque explicarlo requería energía que no tenía, y porque una parte de mí, la parte que todavía funcionaba a nivel mínimo, sabía que si abría la boca iba a tener que admitir cuánto tiempo llevaba llegando a ese punto. Y eso me daba más miedo que el punto en sí.

El orgullo sobrevive incluso al colapso. Eso también es un dato.

Me quedé en el piso. No sé por cuánto tiempo. La mente hace cosas interesantes cuando toca fondo: se vuelve muy clara. Sin el ruido de los procesos ordinarios, sin la carga de los pensamientos cotidianos, queda una especie de silencio cristalino donde podés ver las cosas con una precisión que en condiciones normales resulta imposible.

Vi cuánto tiempo llevaba construyendo una identidad que no era mía. Vi las capas de adaptación, de performance, de ser lo que cada sistema en el que corría esperaba de mí. Vi al chico del 0x01 — el que llegó con el stack trace heredado — y entendí que nunca había parado a preguntar qué quería él, sino solo qué le pedían.

No fue una revelación de luz. Fue más bien un diagnóstico.

El kernel panic no me mató. Pero mató algo: mató la versión de mí que creía que podía seguir corriendo indefinidamente sin atender a los errores de fondo. Mató la ilusión de que podía parchar, workaroundear, forzar el uptime a través de pura voluntad.

A las seis de la mañana mandé un mensaje. Tres palabras. La persona al otro lado apareció dos horas después con café y sin hacer preguntas que yo no pudiera responder todavía.

Eso también es datos para guardar en el log: que en el peor momento, alguien apareció.

No se reinicia de un día para el otro. Pero esa mañana fue el último commit antes del refactor completo.

El sistema no murió esa noche.

Pero el sistema que existía antes, sí.

0x06 :: Recogiendo los pedazos

Sun, 01 Mar 2015 10:14:22 GMT

Después del crash, viene el fsck.

El filesystem check es lo más honesto que existe: no repara, no miente, no suaviza. Recorre cada inodo, cada bloque, cada referencia cruzada, y reporta exactamente lo que encuentra. Bloques perdidos. Entradas de directorio huérfanas. Estructuras que apuntan a datos que ya no existen.

No juzga. Solo informa.

Eso es lo que hice en marzo, con la ayuda de una psicóloga que tampoco juzgaba y que tampoco mentía: un filesystem check de lo que quedaba de mí.

/self: DIRTY. Running fsck...
Checking pass 1 (inodes, blocks, sizes)...
  Inode 0x0012 (identidad): CORRUPTED. Múltiples versiones en conflicto.
  Inode 0x0031 (vínculos): DAMAGED. 3 referencias rotas.
  Inode 0x0044 (límites): NOT FOUND.
Pass 1 done.

Checking pass 2 (directory structure)...
  Entry 'infancia/' points to deleted inode.
  Entry 'relaciones/2008-2013/': INCONSISTENT.
  Entry 'logros/': ACCESSIBLE but EMPTY.
Pass 2 done.

47 errors found. Fix? [y/N]

La respuesta es y. Siempre y. Pero el fsck no garantiza que todo sea recuperable. Hay bloques que están demasiado dañados. Hay datos que se perdieron en algún momento del que no quedó registro y que el sistema movió a /lost+found porque no supo dónde más ponerlos.

Los míos también estaban ahí. Cosas que pertenecían a algún lugar de mí pero que habían quedado desconectadas de su contexto: recuerdos sin estructura, emociones sin etiqueta, capacidades que existían pero que no encontraban su directorio de origen.

El trabajo de ese mes fue mayormente clasificar lost+found.

Lo más difícil no fue encontrar los daños. Los daños estaban donde siempre estuvieron, solo que ahora los miraba sin la capa de negación que antes los hacía invisibles. Lo más difícil fue aceptar que algunos bloques no iban a recuperarse.

No todo se arregla. El fsck no te dice eso explícitamente, pero lo implica: cuando un bloque está sobreescrito, cuando los datos ya no están en ningún lugar recuperable, la única opción honesta es marcar ese espacio como disponible para uso futuro.

Eso también es una forma de sanación. No recuperar. Liberar.

Fui al departamento de mis padres un domingo. Comí con ellos. No expliqué nada, no me preguntaron nada. Hubo un momento, mientras mi madre servía la comida y mi padre ponía música que ninguno de los dos escuchaba de verdad, en que me di cuenta de que seguía existiendo. Que el sistema había sobrevivido al crash. Que el fsck estaba en progreso pero el filesystem seguía montado.

Eso, en ese momento, era suficiente.

0x07 :: Borrado seguro

Mon, 14 Sep 2015 23:41:17 GMT

shred no es rm.

rm borra la referencia. El archivo sigue ahí, en los sectores del disco, esperando ser sobreescrito. Cualquier herramienta de recuperación puede encontrarlo. Le cambiaste el nombre para que el sistema no lo vea, pero el contenido persiste.

shred escribe sobre el espacio. Una vez, tres veces, siete. Sobreescribe los datos con ruido hasta que lo que había antes es irrecuperable. No por negación — por reemplazamiento activo.

Tuve que aprender la diferencia.

Durante meses después del crash usé rm en cosas que necesitaban shred. Pensé que con no pensar en ellas era suficiente. Con no mencionarlas. Con construir nuevas rutinas encima sin desmontar las viejas. El sistema parecía más limpio, pero el disco seguía lleno de versiones anteriores de mí que cualquier momento de debilidad podía recuperar.

Los hábitos son archivos indestructibles. Necesitan sobrescritura, no borrado.

La identidad que tuve que destruir no era completamente falsa. Eso hubiera sido más fácil. Era una mezcla: partes mías reales, mezcladas con capas de adaptación, con máscaras que en algún momento sirvieron y que después se soldaron a la piel sin que lo notara.

Quién era cuando trataba de caerle bien a todo el mundo. Quién era cuando necesitaba que me validaran para creer que lo que hacía valía algo. Quién era cuando ponía las necesidades ajenas antes que las propias como si eso me diera derecho a existir.

Esas versiones merecían un shred, no un archivo.

Fue incómodo. El shred hace ruido. Hay un período en el que no sabés bien quién sos porque lo que eras está siendo sobrescrito y lo nuevo todavía no tiene forma definitiva. Vas por el mundo con el proceso corriendo en background, haciendo cosas cotidianas mientras en algún nivel profundo todo se está reorganizando.

La gente nota algo distinto pero no sabe qué. Algunos lo llaman madurez. Otros lo llaman distancia. Ambas cosas son verdad.

Lo que perdí en ese proceso no fue solo lo malo. Eso también hay que decirlo. Algunas cosas que tenía que dejar ir eran cosas que quería quedarme: una cierta capacidad de maravilla que venía envuelta en ingenuidad, una intensidad de las relaciones que venía envuelta en dependencia, una apertura al mundo que venía envuelta en falta de límites.

No todo lo que se va merece irse. Pero a veces no hay otra forma.

El shred -u borra y libera el espacio en el mismo comando. No deja el inodo vacío apuntando a nada. Libera. Esa u es la diferencia entre borrar y soltar.

Tardé en entenderlo. Que soltar no es olvidar. Que soltar es hacer espacio para algo que todavía no existe, pero que necesita ese espacio para poder ser.

Terminé el proceso en septiembre. No con una ceremonia, no con una declaración. Solo con la sensación, una mañana, de que el ruido de fondo había cambiado. Que lo que escuchaba cuando me quedaba quieto era diferente a lo que había escuchado siempre.

No más silencioso. Diferente.

Más mío.

0x08 :: Nuevos permisos

Wed, 20 Apr 2016 16:30:05 GMT

Los permisos en Unix no son restricciones.

Son declaraciones.

Cuando hacés chmod +x estás diciendo: este archivo tiene derecho a ejecutarse. No es una petición, no es una sugerencia. Es una asignación de capacidad. Le estás dando al sistema la información de que este código puede correr.

Durante años viví con los permisos equivocados sobre mí mismo.

-rw-r--r-- mariano

Legible por todos. Escribible solo para mí. No ejecutable. Disponible para que cualquiera leyera, para que cualquiera opinara, para que cualquiera pusiera ahí sus expectativas y sus necesidades — pero sin capacidad de ejecutar mis propias reglas, mis propios límites, mis propios no.

El primer no real de mi vida adulta llegó tarde. Demasiado tarde para algunos vínculos, justo a tiempo para otros.

No fue un no agresivo. Fue un no tranquilo, casi administrativo. La certeza de que lo que me pedían no era algo que iba a hacer, sin necesitar justificarlo ni apologizarlo ni envolverlo en suficiente amabilidad para que no doliera.

El no sin explicación es el más difícil. Y el más honesto.

chmod +x new_rules fue una operación que tardó meses y que no se hizo de una vez. Fue un conjunto de cambios pequeños, casi imperceptibles en el momento, que en conjunto fueron cambiando los bits de quién tenía permiso de qué sobre mi tiempo, mi energía, mi atención, mi cuerpo.

Dejé de responder mensajes a cualquier hora. Dejé de estar disponible para crisis ajenas que podían esperar a la mañana. Dejé de dar explicaciones por necesitar estar solo. Dejé de pedir disculpas por tener opiniones que diferían de las del cuarto.

La resistencia que encontré fue proporcional a cuánto había entrenado a las personas en que no tendría límites. Eso también fue información útil: los que se enojaron con el cambio eran exactamente los que más se beneficiaban del permissive mode anterior.

No todos los vínculos sobreviven al chmod. Los que sobreviven son los que merecen estar.

Aprender a decir que no fue aprender también a decir que sí con más presencia. Cuando el sí viene de un lugar de elección real, no de miedo a las consecuencias de decir que no, tiene un peso diferente. La persona al otro lado lo nota aunque no sepa nombrarlo.

Mis nuevas reglas no son complicadas:

-rwxr-----  tiempo_propio
-rwxrw----  relaciones_elegidas
-rwx------  decisiones_sobre_mi_cuerpo
-rwx------  voz_en_conversaciones_que_me_involucran

No son perfectas. A veces se me olvida que las tengo y opero en modo legacy por reflejo. Pero el diff entre quien era y quien soy es visible ahora.

Y eso es suficiente.

0x09 :: Punto de restauración

Sat, 31 Dec 2016 23:58:44 GMT

system_restore --point-zero no es factory_reset.

La diferencia es crucial y tardé en aprenderla.

El factory_reset borra todo. Volvés al estado de fábrica, sin historial, sin configuraciones, sin los archivos que fuiste acumulando. Es la opción para cuando querés que parezca que nada pasó. Para cuando la narrativa es: esto no existió, yo no era así, ese período no forma parte de mí.

El system_restore --point-zero hace otra cosa: volvés a un punto de partida, pero te llevás los logs.

Los logs son lo que aprendiste. Los logs son el registro de los errores, los crashes, las correcciones. Sin los logs, el sistema que reinicia está condenado a repetir exactamente los mismos fallos porque no tiene información de qué falló antes.

Quería empezar de nuevo. No quería olvidar por qué.

El último día del año fui a caminar solo por el centro. Hacía calor. Buenos Aires en diciembre tiene ese calor húmedo que se pega a la ropa y a los pensamientos. Caminé sin destino durante dos horas, que es mi forma de hacer las paces con algo que no sé cómo procesar de otra manera.

Hice el inventario mental que hago al final de los años difíciles: qué perdí, qué gané, qué sigue pendiente, qué ya no tiene solución y hay que catalogar como cerrado.

La lista de pérdidas era larga. Algunas las elegí, otras me eligieron. Un vínculo que no sobrevivió al cambio de permisos. Una versión de mí mismo en la que invertí mucho y que tuve que descartar de todas formas. Meses de productividad durante el proceso de recuperación que en el papel parecen tiempo perdido.

El tiempo del duelo siempre parece tiempo perdido desde afuera.

Pero la lista de lo ganado era diferente. No más larga, necesariamente. Diferente en calidad. Más sólida. Las cosas que tenía al final de ese año no las tenía porque me las habían dado o porque las había conseguido por reflejo de supervivencia. Las tenía porque las había elegido, construido, protegido.

Hay una diferencia enorme entre tener algo y haber sobrevivido a no tenerlo y haberlo elegido de todas formas.

El point-zero no es el punto antes del caos. Es el punto después de él, cuando ya corriste el fsck, ya hiciste el shred, ya aplicaste los nuevos permisos. Es el punto donde el sistema tiene toda la información del pasado disponible como logs y puede, por primera vez, tomar decisiones realmente informadas sobre el presente.

En algún momento de esa caminata me senté en un banco que daba al río. El río en la noche es casi negro. Pensé en el niño del 0x01 que llegó al mundo con un stack trace heredado que no pidió. Pensé en todos los errores que vinieron después, los propios y los ajenos, los que causé y los que recibí.

No sentí resentimiento. Eso también fue nuevo.

Sentí algo más parecido a la gratitud por los datos.

Porque cada error, cada crash, cada cosa que funcionó mal y dejó registro, era información. Era el sistema aprendiendo. Era yo, de alguna manera retorcida y costosa, aprendiendo a existir mejor.

Empecé el año siguiente con los logs guardados y los permisos corregidos.

Por primera vez en mucho tiempo, el uptime proyectado parecía indefinido.

0x10 :: Seguir corriendo

Thu, 08 Jun 2017 08:00:00 GMT

#!/bin/bash
# uptime_inf.sh
# Sistema: MARIANO ZAMORA v2.0
# Descripción: Seguir corriendo. Sin fecha de fin.

while true; do
  check_logs
  breathe
  connect --selectively
  create_something
  rest --without_guilt
  sleep 86400
done

El script más honesto que escribí en mi vida.

No porque sea complejo. Sino porque es verdad: no hay salida del loop. El while true es la condición de existir. El sistema corre mientras corre. No hay variable de control, no hay estado final, no hay versión definitiva que sea la correcta y después de la cual todo se detenga.

Eso tardé en entenderlo.

Durante mucho tiempo busqué el estado final. La versión de mí mismo que ya no necesitaba trabajo. El punto de llegada después del cual se podía descansar de verdad, no descanso estratégico para volver a funcionar, sino descanso terminal, el que viene de haber terminado.

Ese punto no existe. El uptime_inf.sh no tiene end condition.

Y eso dejó de asustarme.

Hay algo liberador en entender que el proceso no se termina, que la tarea no es llegar sino seguir corriendo de la manera más íntegra posible. Que el trabajo no es hacerse perfecto sino hacerse más honesto. Más propio. Más capaz de estar presente en cada iteración del loop sin estar mitad de la cabeza en el error del ciclo anterior o en el riesgo del ciclo siguiente.

El script tiene cinco pasos. Ninguno es opcional.

check_logs porque el que no mira hacia atrás no puede aprender. No para quedarse ahí, sino para no repetir. Los logs del 0x01 al 0x09 son parte del sistema ahora, no archivos que se pueden ignorar.

breathe porque el sistema que no descansa crashea. Ya lo sé empíricamente. El descanso no es debilidad ni pérdida de tiempo: es mantenimiento preventivo. El tipo que evita el fsck de emergencia.

connect --selectively porque la conexión es necesaria y los permisos importan. No todos. Los elegidos. Los que el sistema del 0x08 aprendió a proteger.

create_something porque crear es lo que hace que el loop tenga sentido para mí. No sé si para todos. Sé que para mí, un día sin haber hecho algo que antes no existía es un día que el sistema corrió en idle. Funcional, pero sin propósito.

rest --without_guilt porque el flag importa. Sin el flag, el descanso se contamina. Con el flag, es parte del diseño.

Y el sleep 86400 al final: un día a la vez.

No más que eso. El uptime_inf.sh no planifica años, no hace proyecciones de décadas. Corre un día. Después corre otro. La infinitud no está en la planificación sino en la disposición a seguir iterando.

Hay mañanas en que el script falla en el primer paso. Días en que el breathe no funciona bien, en que el connect no tiene con quién, en que el create_something queda en un loop vacío. El sistema no es perfecto. No va a ser perfecto.

Pero está corriendo.

Después de todo lo que documenta este archivo — el stack trace heredado, el ego desbordado, los accesos no autorizados, el agotamiento, el crash del 0x05 donde el directorio de razones estaba vacío — está corriendo.

No como antes. Como algo diferente. Como un sistema que conoce sus propios errores, que tiene mejores prácticas, que aprendió que el uptime no se construye negando los crashes sino incorporándolos como parte del historial.

Seguir corriendo no es un triunfo.

Es simplemente lo que hacen los sistemas que decidieron seguir.

$ ./uptime_inf.sh

[RUNNING] PID: undefined — uptime: ∞