Hay momentos en los que Proxmox no está caído, pero tampoco transmite precisamente paz.
El panel carga a medias. Responde raro. Hace un amago extraño después de tocar certificados. O simplemente alguien te dice que hace un rato iba y ahora va distinto. En ese punto, si ya confirmé que el puerto 8006 escucha y que el nodo responde por HTTPS localmente, suelo ir a una pieza que me gusta bastante más que refrescar la web diez veces.
| |
No tiene glamour, pero me enseña la historia reciente del servicio web con mucha menos fantasía que el navegador.
Y eso es justo lo que quiero.
Quiero ver si ha arrancado, si ha recargado configuración, si ha levantado workers nuevos, si ha cerrado los viejos de forma limpia o si hay señales que de verdad merecen preocupación. No necesito una epopeya. Necesito contexto fresco.
por qué este comando me gusta más que abrir la web otra vez#
Porque la web solo me enseña el síntoma desde mi lado.
El journal me enseña lo que hizo el servicio.
Esa diferencia parece pequeña, pero en práctica cambia muchísimo. Desde el navegador todo se mezcla. Tiempo de carga, caché, cookies, TLS, red, sesión, extensiones, cliente. En los logs del servicio la conversación es bastante más honesta. pveproxy te dice si arrancó, si recibió una señal de recarga, si levantó workers nuevos y si los anteriores salieron como debían.
A mí eso me ordena la cabeza muy rápido.
No siempre encuentro la causa raíz en esta salida, pero casi siempre encuentro la siguiente pregunta correcta. Y en troubleshooting eso ya es media batalla.
la salida real que me interesa leer#
Esta captura sale de un nodo real de mi laboratorio, saneada para no dejar nombres internos que aquí no pintan nada.
Lo que me gusta de esta captura es que no muestra un desastre. Muestra algo mucho más normal y, por eso mismo, muy útil de saber leer.
Veo un arranque del servicio.
Veo después una recarga con Reloading pveproxy.service.
Veo un send HUP al proceso principal.
Veo received signal HUP, server closing, server shutdown (restart) y luego restarting server.
Veo además que levanta tres workers nuevos y, unos segundos más tarde, los workers antiguos salen y quedan marcados como finished.
Eso no me huele a incendio. Me huele a reload razonable.
Y distinguir una recarga limpia de un fallo real me parece importantísimo, porque si no acabas tratando como avería cualquier línea que contenga la palabra shutdown y te montas una película que no tocaba.
qué me cuenta un reload limpio y por qué me tranquiliza bastante#
Una de las cosas que más confunden cuando alguien mira logs de systemd o de un daemon web por primera vez es ver palabras como closing, shutdown o worker exit y pensar automáticamente que algo se ha roto.
No siempre.
En esta captura la secuencia tiene muy buena pinta.
Primero systemd anuncia una recarga.
Luego pveproxy envía una señal HUP al proceso principal. Eso suele cuadrar con una recarga de configuración sin necesidad de derribar el servicio de mala manera.
El proceso principal recibe la señal, cierra el servidor, hace un reinicio controlado y vuelve a levantar workers.
Después los workers viejos van saliendo y el proceso principal deja constancia de que han terminado.
Para mí eso es justo el tipo de transición que quiero ver si he tocado algo en la configuración o si el servicio se ha recargado por una actualización, por un cambio de certificado o por una acción administrativa normal.
No digo que sea bonito. Digo que es sano.
Y eso me tranquiliza bastante más que un panel que simplemente vuelve a cargar sin explicarte qué demonios ha pasado debajo.
cómo leo yo estas líneas sin volverme tonto#
No me quedo a contemplar el log entero. Voy a unas cuantas piezas.
los eventos de arranque#
Las líneas starting server, starting 3 worker(s) y worker X started me importan mucho porque me dicen que el servicio no solo existe en abstracto. También está levantando sus procesos de trabajo como debería.
Si veo el proceso principal pero no veo workers, la cosa cambia.
Si veo workers arrancando y muriendo en bucle, también.
En esta salida el arranque tiene buena pinta.
la recarga anunciada por systemd#
Reloading pveproxy.service me da contexto. No estoy viendo una muerte espontánea sin explicación. Estoy viendo una operación de recarga que el propio sistema reconoce.
Eso ya baja bastante el nivel de paranoia.
la señal HUP#
Esta línea me gusta porque me confirma que la transición no es aleatoria. Hay una señal concreta enviada al proceso principal para que recargue.
Eso encaja con un flujo normal de mantenimiento.
server shutdown (restart)#
Aquí mucha gente se pone nerviosa antes de tiempo.
Yo no, al menos no por esta línea sola.
Si viene encadenada a un reload, a una recepción de HUP y a un nuevo arranque limpio, la leo como parte del ciclo esperado. Me preocuparía mucho más verla repetida una y otra vez sin estabilidad después.
los workers viejos que salen y se marcan como finished#
Esta parte me parece bastante elegante, dentro de lo poco elegante que es mirar logs a las tantas.
Los workers viejos no desaparecen en silencio. Queda constancia de que salen y de que el proceso principal ha visto terminar su trabajo. Esa limpieza me transmite bastante confianza.
señales que me preocuparían bastante más que un reload limpio#
Aquí está la parte práctica de verdad.
Hay patrones que sí me hacen fruncir el ceño mucho más rápido.
- errores repetidos al cargar certificados
- workers que arrancan y mueren en bucle
- mensajes de bind fallido sobre el 8006
- fallos de permisos
- trazas raras de Perl o de módulos que no cargan
- reinicios continuos sin una recarga explícita delante
Eso sí me parece otra película.
Porque entonces ya no estoy viendo una transición razonable. Estoy viendo un servicio que intenta levantarse o mantenerse y no puede hacerlo con estabilidad.
En ese caso el journal deja de ser un sitio para orientarse y pasa a ser el sitio donde probablemente está escrita la causa del problema.
cuándo lo lanzo yo sin pensarlo mucho#
después de confirmar que el 8006 escucha#
Si ss -ltnp | grep 8006 me dice que el puerto está abierto, pero el acceso sigue siendo raro, este suele ser uno de los siguientes pasos.
Quiero saber si pveproxy viene de recargarse, si ha cambiado algo hace poco o si los workers están haciendo cosas raras.
después de una actualización o un cambio de certificado#
Aquí me parece casi obligatorio.
No me gusta asumir que una recarga fue limpia solo porque la interfaz volvió a cargar una vez. Prefiero ver en los logs qué hizo realmente el servicio.
cuando el panel responde, pero con mala espina#
Ese caso lo conozco bien.
No está muerto del todo. Carga a ratos. Se queda pensando. A veces entra y a veces no. Ahí el journal reciente me da pistas mejores que cualquier superstición.
cuando alguien ha tocado el nodo antes que yo#
Esto pasa mucho en laboratorios compartidos o en épocas de mucho trasteo. No siempre sabes qué se cambió hace un rato. El journal reciente te devuelve una pequeña cronología y te ayuda a no entrar a oscuras.
lo que este comando sí me dice#
Me enseña la secuencia reciente del servicio.
Me dice si hubo arranques, recargas y cierres.
Me enseña si se lanzaron workers nuevos.
Me ayuda a distinguir una transición normal de un comportamiento sospechoso.
Y me da un hilo temporal bastante más útil que la sensación vaga de “antes iba y ahora no”.
Para mí eso tiene muchísimo valor.
lo que este comando no me dice#
Tampoco hay que pedirle milagros.
El journal de pveproxy no me confirma por sí solo que el panel sea accesible desde tu cliente.
No me garantiza que una ACL o firewall no corte tráfico.
No me garantiza que el certificado sea aceptado por tu navegador.
No me garantiza que pvedaemon esté sano si luego fallan consola, tareas o acciones.
No me garantiza que pve-cluster o Corosync estén bien si el problema real viene de otra capa.
No me garantiza siquiera que una recarga limpia no haya coincidido con otro problema externo.
Lo que sí hace es contarme la historia reciente de pveproxy. Y esa historia, bien leída, suele ahorrarme varios diagnósticos tontos.
un matiz que me parece clave, reiniciar no siempre es mala señal#
Lo repito porque merece la pena.
En infra tendemos a asociar palabras como restart, shutdown o worker exit con desastre. A veces toca. Pero no siempre.
Un servicio bien diseñado también necesita reiniciar procesos de forma controlada. También necesita recargar configuración. También necesita cerrar workers viejos cuando entran nuevos.
La pregunta buena no es “¿veo una palabra fea?”.
La pregunta buena es “¿la secuencia completa tiene sentido?”.
En la captura que uso aquí, para mí la respuesta es sí.
Hay un antes, un durante y un después coherentes. Hay recarga explícita. Hay HUP. Hay reinicio ordenado. Hay nuevos workers. Hay salida limpia de los anteriores.
Eso me parece un servicio haciendo su trabajo, no un servicio cayéndose de boca.
cómo lo combino con otros comandos de esta serie#
Mi orden habitual, cuando sospecho del panel de Proxmox, suele ser este.
ss -ltnp | grep 8006curl -k -s -o /dev/null -D - https://127.0.0.1:8006/systemctl status pveproxy --no-pagerjournalctl -u pveproxy -n 40 --no-pager- si la cosa sigue rara,
systemctl status pvedaemon --no-pager
Me gusta porque cada paso afina una capa.
ss me dice si el puerto existe.
curl me dice si responde.
systemctl me da la foto general del servicio.
journalctl me cuenta la película reciente con más detalle.
Y si la web carga pero las acciones fallan, entonces me voy a pvedaemon.
Es un orden bastante seco. También bastante rentable.
cómo encaja con otros posts relacionados#
Este post encaja muy bien con otros comandos que ya he publicado en esta serie de Proxmox.
- ss -ltnp | grep 8006 en Proxmox: cómo confirmo quién escucha el panel web antes de culpar a la red o al navegador
- systemctl status pveproxy en Proxmox: cómo separo un panel web caído de un cluster que en realidad sigue bien
- curl -k https://127.0.0.1:8006/ en Proxmox: la prueba local que hago para separar un panel vivo de un problema de acceso
- systemctl status pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras
Juntos forman una secuencia que me parece muy lógica.
Primero confirmo puerto.
Después confirmo respuesta local.
Luego miro servicio.
Y por último leo la historia reciente del servicio.
No será una metodología digna de póster motivacional. Pero para arreglar cosas vale bastante.
mi conclusión#
journalctl -u pveproxy -n 40 --no-pager me parece un comando buenísimo para aterrizar lo que está haciendo de verdad el panel web de Proxmox cuando empieza a dar sensaciones raras. No me da toda la verdad del nodo, pero sí una verdad muy concreta y muy útil sobre el servicio que expone la interfaz y la API.
Lo mejor es que me obliga a leer secuencias, no palabras aisladas. Y eso marca una diferencia enorme. Una recarga limpia no es un drama. Unos workers que salen después de levantar otros nuevos no son, por sí solos, motivo para pulsar el botón rojo.
Cuando el panel me genera dudas, prefiero diez veces esta salida a quedarme refrescando la web como un idiota. El journal suele hablar bastante más claro.
referencias#
- Documentación oficial de
pveproxy - Documentación oficial de
journalctl - Post relacionado: systemctl status pveproxy en Proxmox: cómo separo un panel web caído de un cluster que en realidad sigue bien
- Post relacionado: ss -ltnp | grep 8006 en Proxmox: cómo confirmo quién escucha el panel web antes de culpar a la red o al navegador
- Post relacionado: systemctl status pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras