Hay averías de Proxmox que son bastante honestas.
Fallan, te sueltan un mensaje claro y listo. No hace falta montar una tesis.
Y luego están las otras. Las que se presentan con una consola que tarda, una tarea que responde raro, un storage que a veces sale y a veces no, o una acción desde la web que no termina de cuadrar con la sensación del nodo. Ahí es donde systemctl status pvedaemon me da una foto útil, sí, pero muchas veces se me queda corto. Quiero historia reciente. Quiero saber qué ha pasado hace cinco minutos, no solo si el servicio sigue levantado.
Por eso salto aquí.
| |
No es un comando espectacular. Justo por eso me gusta.
Me enseña las últimas líneas del journal del daemon que está detrás de bastantes tareas y acciones de Proxmox. Si la interfaz va medio normal pero por dentro hay fricción, aquí suelo encontrar la primera pista que merece la pena seguir.
por qué me voy al journal y no me quedo en systemctl status#
Porque systemctl status pvedaemon --no-pager me dice si el servicio vive.
journalctl -u pvedaemon -n 40 --no-pager me dice qué ha hecho.
La diferencia importa bastante. Un servicio puede estar activo y aun así venir dejando detrás errores concretos que no ves tan bien en la vista corta de systemd. Un storage caído. Un intento de autenticación fallido. Un patrón repetido cada pocos minutos. Cosas pequeñas que, cuando las ves seguidas, dejan de parecer anecdóticas.
Yo uso ambos comandos, no uno u otro.
Primero miro el estado. Si el daemon está arriba, perfecto. Después abro el journal para leer el tono de fondo. Ahí es donde muchas veces aparece la pista que la interfaz no te quiere regalar.
la captura real que me parece útil leer#
Esta salida viene de un nodo real de mi laboratorio, saneada para no publicar nombres internos que aquí no pintan nada.
No impresiona mucho, ya lo sé. Tiene cuatro líneas mal contadas.
Precisamente por eso me gusta.
Cuando un journal es corto, cada línea pesa más. No tengo un muro de ruido donde esconderme. Tengo un fallo de autenticación y después varios avisos de que un storage no está online. Nada más. La historia es simple y, por eso mismo, bastante útil.
Ese tipo de salida me ayuda mucho a no inventarme una película más grande de la cuenta.
lo primero que leo, authentication failure no significa automáticamente drama#
La primera línea de la captura enseña un fallo de autenticación para root@pam desde una IP privada.
Esto tiene varias lecturas posibles.
Puede ser una contraseña guardada vieja en un navegador.
Puede ser una automatización que sigue usando credenciales antiguas.
Puede ser alguien que intentó entrar rápido y falló.
Puede ser incluso una herramienta externa golpeando la API con un token o usuario mal configurado.
Lo importante es no convertir esa línea sola en un thriller barato.
Un único authentication failure no me lleva a pensar que el nodo está roto. Me lleva a pensar que hubo un acceso fallido. Punto. Si aparecen decenas, si coinciden con bloqueos, si vienen de un origen raro o si se mezclan con otros síntomas, entonces sube el interés.
Pero una línea sola, sin contexto extra, me parece más una pista operativa que una alarma existencial.
Esto es importante porque en homelab tenemos una capacidad extraordinaria para sobreinterpretar cualquier palabra fea del journal.
A veces toca. A menudo no.
lo que a mí sí me importa de verdad aquí, storage ... is not online#
Las siguientes líneas ya me parecen bastante más accionables.
Tres veces, con minutos de diferencia, pvedaemon deja constancia de que un storage no está online.
Eso me interesa mucho más que el fallo de autenticación.
¿Por qué?
Porque deja de ser un gesto puntual. Ya no parece un clic tonto ni un susto visual en la interfaz. Parece un problema repetido que reaparece cuando el nodo intenta tocar ese almacenamiento.
Y esa es justo la clase de señal que busco en este comando.
No necesito que el journal me escriba una novela. Me basta con que me diga esto con claridad: cada vez que alguien o algo intenta interactuar con ese storage, el daemon vuelve a encontrarse la misma pared.
Ahí ya no estoy en terreno de sensación. Estoy en terreno de patrón.
por qué este comando es tan útil cuando la web miente un poco#
La interfaz de Proxmox engaña. No por mala fe, sino porque es una interfaz.
Puede seguir cargando mientras un storage está medio muerto.
Puede dejarte navegar aunque una tarea vaya a tropezar en cuanto intente tocar cierto recurso.
Puede mostrarte un nodo razonablemente vivo mientras una parte concreta del backend viene chocándose siempre con la misma piedra.
pvedaemon me sirve para discutirle esa falsa tranquilidad a la web.
La pregunta que me ayuda a responder es muy sencilla.
Vale, el panel abre. Pero cuando Proxmox intenta hacer trabajo real, ¿qué se está encontrando por debajo?
Si el journal repite que un storage no está online, ya tengo una respuesta bastante útil. No necesito seguir culpando al navegador, a la caché o a una paranoia abstracta del cluster. Hay una pieza concreta que no responde como debería.
una cosa poco glamurosa que he aprendido, un journal corto vale oro#
Esto cuesta verlo al principio porque asociamos logs útiles con muchas líneas, mucho detalle y mucho texto críptico.
Yo ya no.
Una salida como esta, con cuatro líneas claras, me parece buenísima cuando estoy diagnosticando rápido. Me obliga a no dispersarme. El mensaje es simple.
- hubo un intento de autenticación fallido
- ese storage no está online
- el problema del storage no fue una vez
Con eso ya puedo decidir bastante bien el siguiente paso.
No siempre necesito más.
De hecho, cuando veo un journal kilométrico lleno de ruido irrelevante, muchas veces tardo más en aterrizar que con una salida seca como esta.
cómo interpreto yo la repetición del storage offline#
La repetición es la parte buena del asunto. Buena porque aclara. Mala porque confirma que el problema no se arregló solo.
La primera vez podría ser casualidad. Una llamada puntual. Una comprobación aislada. Una consulta en mal momento.
La segunda y la tercera ya cambian el tono.
Si pvedaemon vuelve a escribir lo mismo con distintos PID y con varios minutos de separación, me interesa menos la línea concreta y más el comportamiento que revela. Hay trabajo real intentando usar ese storage, y ese trabajo sigue encontrándose el mismo resultado.
Eso suele llevarme a revisar cuatro cosas antes de tocar nada más sofisticado.
que el storage exista de verdad y esté accesible#
Suena ridículo, pero a veces el problema es justo ese. Un NFS o CIFS que no está montado. Un destino que resolvía y ahora no. Un recurso externo que está caído.
Aquí me suele venir bien volver a pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro.
que el fallo no venga de red#
Si el storage vive fuera del nodo, red y storage van de la mano aunque nos guste separarlos mentalmente.
No hace falta un drama de cluster para que un almacenamiento remoto quede como offline. Basta con un corte, una ruta rota, una credencial mal, o un destino que simplemente no responde.
que no esté fallando una tarea concreta y no el storage entero#
A veces el storage en sí existe, pero la tarea que lo toca lo hace en mal momento o con un bloqueo raro. Por eso no me quedo solo con esta línea. La uso para orientar el diagnóstico, no para cerrar el caso antes de tiempo.
que pvestatd no venga contando la misma historia por otro lado#
Si el problema es de visibilidad o refresco del estado del storage, me gusta cruzarlo con systemctl status pvestatd en Proxmox: cómo leo el daemon que refresca estado, storage y métricas cuando un nodo empieza a oler raro.
Ahí a veces encajan piezas bastante rápido.
lo que me dice esta salida sobre pvedaemon#
Me dice algo bastante humilde, pero muy útil.
El daemon no solo está corriendo. También está dejando un rastro claro de qué operaciones le están molestando.
Y eso cambia mucho la forma de trabajar.
Si un servicio está activo pero silenciosamente frustrado, la interfaz te puede mantener entretenido más de la cuenta. El journal, en cambio, suele tener menos paciencia. Si una operación real falla, a menudo te la escupe sin maquillaje.
Aquí el maquillaje sería pensar que todo va medio bien porque el panel sigue abriendo.
El journal me contesta algo más áspero. No, colega. Hay un storage offline y estás tropezando con él una y otra vez.
Ese tipo de franqueza me ahorra bastante tiempo.
cuándo lanzo yo este comando sin pensármelo demasiado#
cuando una tarea falla y el mensaje de la interfaz me sabe a poco#
Hay errores que el panel resume peor de lo que me gustaría. Otras veces el popup desaparece y te deja con una idea demasiado genérica. El journal del daemon me devuelve algo más cercano al hecho real.
cuando el storage se comporta de forma inconsistente#
Si un almacenamiento sale online a ratos, tarda en responder o deja tareas colgadas, esta es una parada bastante buena.
cuando el nodo parece sano pero no me lo creo#
Esto me pasa bastante. La web abre, el servicio está activo, todo parece más o menos normal. Aun así, algo no huele bien. Aquí el journal me ayuda a comprobar si esa sospecha era paranoia o había motivo.
después de una incidencia corta que ya pasó#
Este punto me gusta mucho. A veces llegas tarde al fallo. Ya no está ocurriendo delante de ti. El panel volvió, la tarea terminó, el susto pasó. journalctl -u pvedaemon -n 40 --no-pager te deja una historia reciente que a veces basta para reconstruir lo esencial.
lo que este comando no me dice#
Conviene no darle poderes mágicos.
No me confirma por sí solo que el problema esté enteramente dentro de pvedaemon.
No me dice si el storage cayó por red, por permisos, por el destino remoto o por otra dependencia.
No me garantiza que el resto del nodo esté perfecto.
No me sustituye revisar pve-cluster, Corosync o el propio estado del almacenamiento.
No me cuenta toda la traza de una tarea compleja.
Y, detalle importante, tampoco me asegura que un journal vacío sea buena noticia. A veces un -- No entries -- solo significa que ese servicio no ha tenido nada digno de registrar en el intervalo disponible. Ni fiesta ni desastre.
Lo que sí hace es darme la última capa de contexto operativo del daemon. Para una primera criba, me parece mucho.
un matiz que me parece importante, el PID cambia y eso también cuenta#
En la captura los avisos del storage vienen asociados a distintos PID.
No me obsesiono con eso, pero sí me fija una idea útil. No parece el mismo proceso repitiendo en bucle una línea vieja. Parece actividad real, en momentos distintos, chocando con el mismo problema.
Eso refuerza la lectura de que el storage está efectivamente inaccesible cuando se le toca.
No es una prueba absoluta de nada. Pero sí otra pequeña pieza que inclina la balanza hacia un problema persistente y no hacia una simple anécdota de logs.
cómo lo combino con el resto de mi secuencia#
Cuando el síntoma apunta a tareas o backend local, mi orden corto suele ser este.
systemctl status pvedaemon --no-pagerjournalctl -u pvedaemon -n 40 --no-pagerpvesm statussystemctl status pvestatd --no-pager- si sospecho capa compartida,
systemctl status pve-cluster --no-pager
Me gusta porque no salta demasiado rápido a teorías grandes.
Primero confirmo que la pieza local vive.
Luego miro qué viene diciendo.
Después bajo al almacenamiento.
Y solo si hace falta me voy a la capa del cluster.
Ese orden me parece bastante más rentable que empezar culpando a quorum, Corosync o al universo entero cuando lo único que pasa es que un NFS se fue a tomar por saco.
por qué me gusta tanto para problemas “a medias”#
Porque Proxmox está lleno de problemas a medias.
No completamente roto.
No completamente sano.
Ese terreno gris donde el panel existe, el nodo responde, pero algo importante chirría. En ese terreno, el journal de pvedaemon encaja de maravilla porque no intenta resumir el mundo. Solo deja pequeñas huellas del trabajo real que ha pasado por ahí hace poco.
Y con esas huellas, muchas veces basta.
No me hace falta una plataforma de observabilidad futurista para concluir que el problema del momento no es la interfaz ni la imaginación. El storage está offline. Fin.
A partir de ahí ya puedo preguntar por qué. Antes no.
cómo encaja con otros posts de esta serie#
Este comando forma una pareja natural con varios posts que ya he publicado sobre Proxmox.
- systemctl status pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras
- pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro
- systemctl status pvestatd en Proxmox: cómo leo el daemon que refresca estado, storage y métricas cuando un nodo empieza a oler raro
- systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
El hilo lógico, al menos para mí, es bastante terrenal.
Miro estado.
Leo journal.
Compruebo storage.
Y solo entonces subo al cluster si el caso lo pide.
No será muy sexy, pero funciona bastante.
mi conclusión#
journalctl -u pvedaemon -n 40 --no-pager me parece uno de esos comandos modestos que conviene tener muy cerca si administras Proxmox de verdad y no solo desde el panel. No porque resuelva solo una incidencia compleja, sino porque suele contarte la parte útil de la historia reciente sin adornos ni distracciones.
En la captura que uso aquí no hay fuegos artificiales. Hay un fallo de autenticación y un storage offline que reaparece varias veces. Y, sinceramente, eso ya es una barbaridad de contexto para un comando tan simple.
Cuando una tarea me deja mala espina o el nodo actúa raro pero no lo suficiente como para caerse del todo, prefiero esto a quedarme pulsando botones en la web como un idiota. El journal de pvedaemon suele hablar bastante más claro.
referencias#
- Documentación oficial de
journalctl - Documentación oficial de
pvedaemon - Post relacionado: systemctl status pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras
- Post relacionado: pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro
- Post relacionado: systemctl status pvestatd en Proxmox: cómo leo el daemon que refresca estado, storage y métricas cuando un nodo empieza a oler raro