Solución de problemas

Busque en esta página el mensaje exacto que ve (Ctrl + F, o ⌘ + F en Mac): la mayoría de las entradas parten de lo que dice el panel, un correo, el instalador o un registro. Las preguntas frecuentes responden las dudas generales. Si nada de esto le ayuda, consulte Obtener ayuda.

Los registros (journalctl) siempre están en inglés; el panel, los correos, el instalador y el comando 3rmonitor muestran los mensajes en su idioma cuando tienen traducción.

Primeras comprobacionesCopy Anchor Link

Estos comandos responden la mayoría de las preguntas. Ejecútelos en el servidor en cuestión:

3rmonitor status                       # modo de instalación y estado de los servicios
3rmonitor version                      # versión instalada
journalctl -u 3rmonitor-master -n 50   # últimas líneas del registro del servidor principal (en el servidor principal)
journalctl -u 3rmonitor-agent -n 50    # últimas líneas del registro del agente (en un servidor con agente)
journalctl -u 3rmonitor-helper -n 50   # últimas líneas del registro del ayudante root del agente
sudo 3rmonitor agent --test            # el agente reporta una vez y muestra el resultado

Dónde aparecen los mensajes:

Muchos problemas ya están corregidos en una versión más reciente: revise primero Sistema → Actualizaciones de software.

InstalaciónCopy Anchor Link

El comando de instalación fallaCopy Anchor Link

"La descarga falló: verifique que el servidor principal sea accesible, que el token o la clave de registro sean correctos y que el servidor principal se haya instalado con el paquete de distribución completo" significa una de estas tres cosas:

• el servidor no puede llegar a la dirección del panel (pruebe con curl -I), o la Dirección pública del panel de Configuración → General es una dirección a la que el servidor no puede llegar (por ejemplo, una IP de la red local desde otra red);
• el token o la clave de registro ya no son válidos: vuelva a copiar el comando de Servidores;
• el servidor principal no tiene los paquetes del agente. La página Servidores muestra entonces el aviso "El directorio dist del servidor principal no contiene los paquetes del agente". Reinstale el servidor principal con el paquete de distribución completo: sudo bash install.sh upgrade en el paquete descomprimido.

Para ver el motivo, pruebe la descarga usted mismo: curl -v "URL_DEL_SERVIDOR_PRINCIPAL/dl/SHA256SUMS?t=TOKEN". Una respuesta 401 significa que el token o la clave no son correctos; 404, que el servidor principal no tiene los paquetes del agente.

Otros mensajes del instalador (✗ se detuvo o falló, ! es una advertencia; ambos se repiten en el resumen final):

sudo indica "command not found"Copy Anchor Link

En AlmaLinux, Rocky, RHEL y CentOS, sudo solo busca en /usr/sbin y /usr/bin. Antes de la 1.1.1 el comando 3rmonitor solo estaba en /usr/local/bin, así que sudo 3rmonitor … respondía "sudo: 3rmonitor: command not found". Desde la 1.1.1 el comando también se enlaza en /usr/bin: actualice, y los servidores obtienen el enlace solos. Mientras tanto, puede:

• abrir una consola de root con sudo -i y ejecutar ahí los comandos sin sudo, o
• escribir la ruta completa: sudo /usr/local/bin/3rmonitor status.

La línea de comandosCopy Anchor Link

Un comando indica "Error"Copy Anchor Link

La mayoría de los comandos 3rmonitor necesitan root. Sin sudo, algunos fallan y otros dan una respuesta engañosa:

3rmonitor status no muestra el ayudante: compruébelo con systemctl status 3rmonitor-helper.

"approvers trust" no confía en las clavesCopy Anchor Link

El panelCopy Anchor Link

El panel no abreCopy Anchor Link

1. ¿Se está ejecutando el servidor principal? sudo systemctl status 3rmonitor-master. Si no, el registro (journalctl -u 3rmonitor-master -n 50) indica por qué, por ejemplo un puerto que ya está en uso o un archivo de certificado que no puede leer.
2. ¿Está abierto el puerto? El instalador lo abre en ufw o firewalld, pero los proveedores de nube suelen tener su propio firewall (grupos de seguridad) delante del servidor. Abra también allí el puerto 8899 (o su puerto).
3. ¿Escucha solo en 127.0.0.1? Si listen en /etc/3rmonitor/master.conf es 127.0.0.1:8899, el panel solo es accesible mediante el proxy inverso (su dominio), no por IP.
4. Con un dominio: compruebe que Nginx o Apache se esté ejecutando y que el DNS del dominio apunte al servidor principal.

Una página indica "No se pudo cargar esta página"Copy Anchor Link

El navegador no pudo obtener los datos de la página del servidor principal: se cortó la conexión, el servidor principal se reinició (por ejemplo durante una actualización) o falló un proxy inverso intermedio. El mensaje breve de la esquina muestra el error. Haga clic en Reintentar. Si se repite, compruebe que el servidor principal esté en ejecución y revise su registro; detrás de Nginx o Apache, revise también el registro de errores del proxy.

Olvidé la contraseñaCopy Anchor Link

En el servidor principal: sudo 3rmonitor user passwd USUARIO, y luego indique la contraseña nueva. sudo 3rmonitor user list muestra los nombres de usuario.

Con más de 5 intentos fallidos de un mismo usuario, o 10 desde una misma IP, en 15 minutos, el inicio de sesión se bloquea: "Demasiados intentos fallidos de inicio de sesión. Inténtelo de nuevo en 15 minutos." Mientras tanto se rechaza incluso la contraseña correcta. Espere, o reinicie el servidor principal (sudo systemctl restart 3rmonitor-master), lo que pone el contador a cero.

Detrás de un proxy inverso que no está en la misma máquina, en la red local ni en Cloudflare, todos los visitantes parecen venir de la IP del proxy, así que unos pocos fallos bloquean a todos. Si al panel solo se puede llegar a través de ese proxy, configure trust_proxy = true en master.conf (consulte Archivos de configuración).

Otros mensajes del panelCopy Anchor Link

Al iniciar sesión vuelvo a la página de inicio de sesiónCopy Anchor Link

Esto ocurría en las versiones anteriores a 1.0.4 cuando la URL del panel era https:// pero la página se abría con http:// (por ejemplo, por IP). Actualice a la versión más reciente. Compruebe también que el navegador acepte cookies para la dirección del panel.

El navegador indica "No seguro"Copy Anchor Link

El panel se sirve por http://. Configure HTTPS.

Agentes y servidoresCopy Anchor Link

Un agente no reportaCopy Anchor Link

Ejecute en el servidor del agente:

sudo 3rmonitor agent --test

Reporta una vez y muestra el resultado. Después:

En el registro del agente (journalctl -u 3rmonitor-agent), "Report failed (attempt N): …" da el motivo; se escribe en el primer fallo y luego cada 20. "connection refused" significa que nada escucha en esa dirección y puerto, o que un firewall la rechaza; "i/o timeout" o "Client.Timeout exceeded", que un firewall descarta la conexión en silencio. "Connection to the master restored" indica que vuelve a funcionar.

Para ver lo que recopila el agente sin enviar nada: sudo 3rmonitor agent --print.

Todos los servidores aparecen sin conexión a la vezCopy Anchor Link

Si 3 o más servidores dejan de reportar en el mismo momento, recibe una sola alerta: "Los N servidores dejaron de reportar al mismo tiempo". Casi con seguridad los servidores están bien: es el servidor principal el que no recibe los reportes. Revise la red del servidor principal, su firewall (y el del proveedor), su proxy inverso y su certificado, y si cambió la dirección del panel o el registro DNS.

Dos servidores muestran los mismos datosCopy Anchor Link

El panel muestra un servidor cuyos datos saltan entre dos máquinas, o "Reporting too often" en el registro: dos máquinas usan el mismo token. Ocurre cuando se clona un servidor (una plantilla o una instantánea de VM) con /etc/3rmonitor/agent.conf. Dé de alta la copia como un servidor propio (Servidores → ＋ Agregar servidor) y, en la copia, ejecute el comando bind que le indica:

sudo 3rmonitor bind --master 'https://monitor.example.com' --token 'TOKEN_NUEVO'

Para crear plantillas, desinstale antes el agente, o instálelo con la clave de registro cuando arranca cada máquina (por ejemplo con cloud-init).

La página del servidor indica "El ayudante de 3R Monitor no está en ejecución"Copy Anchor Link

El agente se ejecuta como usuario sin privilegios y hace lo que necesita root a través de 3rmonitor-helper. Sin él, el agente sigue monitoreando, pero la IA, la lista de bloqueo y algunos datos (los procesos detrás de los puertos, el estado de MySQL) no funcionan allí.

sudo systemctl restart 3rmonitor-helper
journalctl -u 3rmonitor-helper -n 50

Si no arranca, o la página dice "El agente todavía se ejecuta como root…" o "No se pudo cambiar el agente a un usuario sin privilegios: …", ejecute sudo 3rmonitor agent secure y lea lo que responde: por ejemplo "neither useradd nor adduser is available" (instale el paquete passwd o shadow-utils), o "the helper did not start (…)". Necesita systemd.

Un agente se queda en una versión anteriorCopy Anchor Link

Los agentes se actualizan solos a la versión del servidor principal. Si uno no lo hace:

• no puede llegar al servidor principal (consulte Un agente no reporta);
• tiene auto_update = false en su agent.conf;
• desde la 1.1.1, los agentes solo instalan programas firmados por 3R Soft. Si Sistema → Paquetes del agente muestra Sin firma, el servidor principal no se instaló ni se actualizó con el paquete de distribución oficial: ejecute sudo bash install.sh upgrade desde el paquete oficial. El registro del agente indica entonces "Automatic update failed: the master has no signature for the agent packages…" o "…are not signed for …".

También puede actualizar un agente manualmente con el paquete de distribución: sudo bash install.sh upgrade en su directorio.

El uso de tráfico parece incorrectoCopy Anchor Link

• Empieza en un día reciente: el conteo empezó cuando se actualizó el servidor principal a la 1.1.1 («Contado desde …»).
• «El agente no informa de … por separado»: eligió una interfaz en Servidores → Configuración → Uso de tráfico, pero el agente es anterior a la 1.1.1 o esa interfaz ya no existe, así que se cuentan todas las interfaces. Espere a que el agente se actualice, o elija otra interfaz.
• No coincide con la cifra de su proveedor: consulte Uso de tráfico. Cuente solo la interfaz que factura su proveedor, elija cómo cuenta la cuota (descarga, subida, ambas o la mayor) y recuerde que aquí 1 GB son 1024³ bytes.
• Falta un día: el agente no reportó ese día (el servidor o el agente estaban detenidos). El tráfico de ese tiempo se cuenta el día en que vuelve a reportar, salvo que el servidor se haya reiniciado entretanto.

Un servidor aparece en el lugar equivocado del mapaCopy Anchor Link

Indique su posición en Servidores → Configuración → Ubicación en el mapa. La posición del propio servidor principal está en Configuración → Mapa. Consulte Posición de los servidores.

MySQL / MariaDB indica "No se puede iniciar sesión en la base de datos"Copy Anchor Link

El agente no puede iniciar sesión para leer el estado de la base de datos. Consulte Credenciales de MySQL para el agente. Además:

• "No se encontró el cliente mysql; no se puede leer el estado del servidor": instale el cliente mysql o mariadb en ese servidor.
• En Debian y Ubuntu, /etc/mysql/debian.cnf solo se usa mientras el ayudante está en ejecución: consulte el ayudante no está en ejecución.
• "Redis requiere contraseña; no se leyó su estado": solo informativo, Redis se sigue monitoreando como servicio.

Una alerta de servicio que no entiendoCopy Anchor Link

Alertas y correosCopy Anchor Link

Los correos de alerta no lleganCopy Anchor Link

1. Abra Sistema → Correos recientes: cada correo muestra si se envió, si se está reintentando o si se abandonó, y el error.
2. Envíe una prueba: Configuración → Correo saliente (SMTP) → Enviar un correo de prueba, o sudo 3rmonitor mail-test --to usted@example.com en el servidor principal.
3. Causas frecuentes:
   • Gmail requiere una contraseña de aplicación, no la contraseña normal.
   • Muchos proveedores de nube bloquean el puerto 25 saliente. Use 465 (SSL) o 587 (STARTTLS).
   • El Cifrado no corresponde al puerto: SSL con 465, STARTTLS con 587.
   • El servidor tiene Activar alertas desactivado en su configuración, o ese tipo de alerta está desactivado en Configuración → Notificaciones de alertas → Enviar correos sobre.
   • El correo llegó a la carpeta de spam. Indique una Dirección del remitente de un dominio en nombre del cual el servidor SMTP tenga permiso para enviar.
   • Sistema muestra Destinatarios de alertas: Sin definir: sin destinatarios no se envía nada, y solo el registro del servidor principal lo indica.

El error de un correo fallido, en la prueba o en Sistema → Correos recientes:

Los correos fallidos se reintentan hasta 12 veces, esperando cada vez más (unas 6 horas en total), y luego se marcan como Abandonado.

Los correos de alerta llegan tardeCopy Anchor Link

Normalmente es a propósito:

• Las alertas se combinan: la primera se envía después de 1 minuto y luego, como máximo, un correo cada 5 minutos. Configure Configuración → Notificaciones de alertas → Combinar correos de alerta (minutos) en 0 para enviar cada alerta de inmediato.
• Con el análisis de IA, un correo sobre una caída nueva espera hasta unos dos minutos más para incluir la causa probable.
• Por encima del Máximo de correos por hora (10 de forma predeterminada), los correos esperan en la bandeja de salida. Sistema muestra cuántos hay en cola.

La IA encontró algo, pero no me envió un correoCopy Anchor Link

La IA solo envía por correo lo que requiere de usted, y como máximo IA → Configuración → Correos de la IA → Correos por día (5 por defecto). Cada investigación indica en su línea de tiempo si envió un correo, y por qué no:

Las tareas que usted le da a la IA nunca se envían por correo. Las alertas del sistema (servidores, servicios, monitores, certificados, discos, cuotas de tráfico) no dependen de esto. Consulte Correos de la IA.

MonitoresCopy Anchor Link

Un monitor indica "caído" pero el sitio funcionaCopy Anchor Link

La comprobación se ejecuta desde el servidor principal, así que lo que importa es lo que ve el servidor principal. Pruebe desde el propio servidor principal:

curl -sv -o /dev/null https://example.com/health

• HTTP 403 "posiblemente bloqueado por un desafío de Cloudflare": permita la IP del servidor principal en Cloudflare o en su WAF.
• HTTP 301/302 cuando esperaba 200: las redirecciones se siguen de forma predeterminada; si marcó No seguir redirecciones, agregue el código a Código de estado esperado (por ejemplo 200,301).
• "… no se encontró … en la página": la palabra clave distingue mayúsculas y minúsculas, y solo se leen los primeros 2 MB de la respuesta.
• Tiempo de espera agotado: aumente Tiempo de espera (s) si el punto de acceso es lento, o compruebe que el servidor principal pueda llegar a él (firewall, IPv6, DNS).
• Error de certificado: el certificado venció o está incompleto. Para un certificado autofirmado, marque No verificar el certificado.

Haga clic en Probar en el formulario del monitor para ver el mensaje exacto. Qué significan los mensajes:

Un monitor Ping siempre aparece caídoCopy Anchor Link

Ping usa ICMP, que muchas redes y proveedores de nube bloquean. Si ICMP está bloqueado entre el servidor principal y el host, use en su lugar un monitor de Puerto TCP (por ejemplo host:22 o host:443). El servidor principal también necesita el comando ping; si falta, indica "El comando ping no está disponible en este sistema".

Cada comprobación envía un solo paquete, y cualquier fallo de ping se muestra como "Sin respuesta (pérdida de paquetes)", también cuando el servidor principal no tiene permiso para enviar ICMP. Pruebe desde el servidor principal con ping -c 1 HOST.

Tráfico y lista de bloqueoCopy Anchor Link

No hay estadísticas de tráficoCopy Anchor Link

• El agente lee los registros de acceso de Apache y Nginx en las ubicaciones habituales. Si los suyos están en otro lugar, configure access_logs en /etc/3rmonitor/agent.conf (por ejemplo access_logs = /data/logs/*.access.log) y reinicie el agente.
• Desde la 1.1.0, el agente se ejecuta con el usuario sin privilegios 3rmonitor-agent, y el instalador le da acceso de lectura a los registros con setfacl. Si faltaba el paquete acl, el registro del agente indica "The agent (user 3rmonitor-agent) cannot read the access logs in …": instale acl y vuelva a ejecutar sudo 3rmonitor agent secure. Haga lo mismo después de configurar access_logs con una ubicación nueva.
• access_logs reemplaza las ubicaciones habituales, no se suma a ellas: indique todas las ubicaciones que necesita.
• Los registros rotados y comprimidos (access.log.1, access_log-20261020, .gz) y los registros de errores se omiten a propósito.
• access_logs = off desactiva las estadísticas.
• Los países requieren la base de datos de IP por país. La página Sistema muestra si está cargada y cuándo se actualizó por última vez.
• Detrás de Cloudflare, todas las solicitudes vienen de Cloudflare hasta que el servidor de origen recupere la IP real. Consulte los consejos para Cloudflare.

La lista de bloqueo no bloqueaCopy Anchor Link

Al agregar una regla, el panel rechaza lo que haría daño:

Quedé bloqueado por la lista de bloqueoCopy Anchor Link

Desde la consola del servidor (la consola web de su proveedor, si SSH está bloqueado):

sudo 3rmonitor firewall off

Las reglas de bloqueo se eliminan de inmediato. Corrija las reglas en Tráfico → Listas de bloqueo / permitidos y luego ejecute sudo 3rmonitor firewall on. Para evitarlo en el futuro, configure La lista de bloqueo solo bloquea estos puertos como 80,443.

Desde la 1.1.1, las reglas de país y los rangos mayores que /24 nunca bloquean el puerto SSH, así que solo una regla para su propia IP o un rango pequeño que la incluya puede dejarlo sin SSH.

Un país bloqueado todavía puede conectarse por SSHCopy Anchor Link

Es a propósito desde la 1.1.1: las reglas de país y los rangos grandes bloquean todos los puertos excepto SSH, para que usted siempre pueda volver a entrar. Para bloquear SSH a un atacante, bloquee su IP o un rango pequeño (/24 o menos). Consulte Para no quedarse bloqueado.

VulnerabilidadesCopy Anchor Link

Un servidor no muestra vulnerabilidades, o no se compruebaCopy Anchor Link

La página Seguridad indica el motivo arriba:

Fuentes de datos y cómo se compara muestra cuándo se actualizó cada fuente. «Error: …» ahí significa que el servidor principal no puede llegar a ella: necesita HTTPS saliente hacia api.osv.dev, services.nvd.nist.gov, www.cisa.gov, endoflife.date, cveawg.mitre.org, raw.githubusercontent.com y github.com. «NVD: HTTP 403» o «429» significa que NVD está limitando las solicitudes: agregue una clave de API de NVD gratuita en Configuración → Comprobación de vulnerabilidades.

Una vulnerabilidad que corregí sigue en la listaCopy Anchor Link

• El agente sube una lista de software nueva cuando el software cambia, y todo se vuelve a comprobar cada 6 horas. Haga clic en Analizar ahora en la página Seguridad para comprobar de inmediato.
• Actualice los paquetes de «instalado como …», no el nombre del paquete fuente del título: por ejemplo perl-base, no perl.
• «No se actualizó nada: las fuentes de paquetes configuradas no tienen una versión más nueva…»: la distribución todavía no publicó la corrección, o las fuentes de paquetes del servidor están desactualizadas. Marque Ocultar las que aún no tienen versión corregida para ocultar esas vulnerabilidades, o Ignore esta con un motivo.
• Si el servicio debe reiniciarse para usar la versión nueva, puede que siga en ejecución la anterior: reinícielo.

La IACopy Anchor Link

La IA no ejecuta nada en un servidorCopy Anchor Link

IA → Guardia → Servidores donde la IA puede hacer menos y la fila Agente de la pestaña Sistema del servidor indican el motivo. En orden:

La prueba del modelo falla, o fallan los informesCopy Anchor Link

El error aparece en el mensaje de Probar, en el informe («El informe falló: …») o en una investigación («El modelo falló: …»):

Una investigación se detuvo, o la IA solo sugiere reparacionesCopy Anchor Link

Cuando el propio servidor rechaza una operación, la operación indica por qué:

Una reparación se rechazó con "Límite en este servidor"Copy Anchor Link

Desde la 1.1.1, cada servidor limita por sí mismo las reparaciones aprobadas solo por la IA revisora:

• «Límite en este servidor: esta reparación ya se ejecutó 3 veces en la última hora»: la misma reparación vuelve una y otra vez, así que la causa está en otra parte. Revise la investigación y corrija usted la causa.
• «Límite en este servidor: N reparaciones automáticas en las últimas 24 horas (ai_auto_per_day en agent.conf)»: suba ai_auto_per_day en el agent.conf de ese servidor si de verdad quiere más, o apruebe usted la reparación: las que usted aprueba no tienen este límite.

"Esta conversación está cerrada"Copy Anchor Link

La conversación de una tarea se puede continuar durante 24 horas después de la última respuesta de la IA. El mensaje indica por qué se cerró (se detuvo, se alcanzó un límite, el modelo falló…): dele a la IA una tarea nueva. Consulte Continuar una tarea.

Llaves de accesoCopy Anchor Link

No puedo agregar una llave de acceso, o una aprobación fallaCopy Anchor Link

• Las llaves de acceso necesitan el panel en HTTPS (o localhost): el botón ＋ Agregar llave de acceso está desactivado en un panel http://. Abra el panel en su dirección https://. Consulte HTTPS.
• "Este navegador no admite llaves de acceso" o "no puede registrar llaves de acceso": use una versión actual de Chrome, Edge, Safari o Firefox.
• "La solicitud de llave de acceso se canceló o caducó": vuelva a intentarlo y confirme en menos de dos minutos.
• Una llave de acceso solo funciona en el nombre de host en el que se creó. Abra el panel en la misma dirección.
• Una llave de acceso nueva se queda en Esperando una firma hasta que un administrador con una llave de acceso de confianza la confirme.
• "La aprobación se firmó con una llave de acceso en la que este servidor no confía": ejecute sudo 3rmonitor approvers trust en ese servidor.
• Una aprobación es válida durante una hora. Después, la operación se marca como Vencida.
• "Las aprobaciones se firman con una llave de acceso. Agregue una primero en Configuración → Llaves de acceso": todavía no tiene una llave de acceso.
• "Firme la aprobación con su llave de acceso (la solicitud caducó o la operación cambió); inténtelo de nuevo": la solicitud es válida durante 5 minutos.
• "Firme con una de sus propias llaves de acceso de confianza": la llave de acceso que usó sigue Esperando una firma, o es de otra persona.
• "La respuesta del navegador no coincide con la solicitud": el panel se abrió en una dirección distinta de la suya. Use la dirección pública del panel.
• "Esta llave de acceso ya está registrada": ese dispositivo ya tiene una llave de acceso para este panel.
• Configuración → Llaves de acceso muestra "Todavía no confía: en el servidor ejecute sudo 3rmonitor approvers trust…" después de su primera llave de acceso: cada servidor debe confiar en ella una vez, también los servidores instalados antes de que usted tuviera una llave de acceso.
• Si se pierden todas las llaves de acceso, consulte Llaves de acceso.

Un servidor se queda en "obteniendo el registro más reciente…"Copy Anchor Link

Desde la 1.1.1, los servidores aplican un registro nuevo de llaves de acceso en segundos, y Configuración → Llaves de acceso se actualiza sola mientras tanto. Si un servidor se queda ahí, su agente no puede llegar al servidor principal, o su ayudante no está en ejecución: revise systemctl status 3rmonitor-helper y journalctl -u 3rmonitor-helper -n 50 en ese servidor.

ActualizacionesCopy Anchor Link

La actualización se descargó, pero no se instalóCopy Anchor Link

Desde la 1.1.1, no se instala nada hasta que usted lo confirme. Sistema → Actualizaciones de software dice «x.y.z está descargada y su firma comprobada. Se instala solo cuando usted lo confirme.»: haga clic en Instalar ahora… o en Instalar. «Esta versión aún no se ha descargado; descárguela primero» significa que falta la descarga o que se publicó una versión más nueva: vuelva a hacer clic en Actualizar ahora.

Falló una actualización desde el panelCopy Anchor Link

La tarjeta Sistema → Actualizaciones de software muestra el error y la salida del instalador. Siempre puede actualizar manualmente con sudo bash install.sh upgrade desde el paquete nuevo.

El servidor principal no arranca después de una actualizaciónCopy Anchor Link

Desde la 1.1.1, install.sh ejecuta el servidor principal en un aislamiento de systemd más estricto. En los pocos sistemas que no lo admiten (algunos contenedores LXC), el instalador lo quita por sí mismo e indica "Este equipo no admite el aislamiento adicional del servidor principal…". Si el servidor principal aun así no arranca, revise journalctl -u 3rmonitor-master -n 50 y quite el aislamiento manualmente:

sudo rm -r /etc/systemd/system/3rmonitor-master.service.d
sudo systemctl daemon-reload && sudo systemctl restart 3rmonitor-master

Obtener ayudaCopy Anchor Link

Si esta página y las preguntas frecuentes no lo resuelven:

1. Actualice a la versión más reciente (Sistema → Actualizaciones de software): puede que el problema ya esté corregido.
2. Escriba a info@3rsoft.com.pa. En el panel, Sistema → Ayuda y soporte → Problemas o errores abre un correo con su versión en el asunto.

Para obtener una respuesta en el primer correo, incluya:

• qué hizo, qué esperaba y qué pasó en su lugar, con el mensaje exacto o una captura de pantalla;

• la salida de estos comandos en el servidor en cuestión (el servidor principal, o el servidor con agente):

  Copy Text

  3rmonitor version
  3rmonitor status
  cat /etc/os-release
  journalctl -u 3rmonitor-master -n 100 --no-pager   # en el servidor principal
  journalctl -u 3rmonitor-agent -n 100 --no-pager    # en un servidor con agente
  journalctl -u 3rmonitor-helper -n 100 --no-pager   # en un servidor con agente
  sudo 3rmonitor agent --test                        # en un servidor con agente

• para un problema de instalación, la salida completa del instalador.

No envíe agent.conf, master.conf, tokens, claves de registro, contraseñas ni claves de API: nadie en 3R Soft los necesita. Reemplácelos por … si aparecen en lo que copia.

Reporte los problemas de seguridad de forma privada a security@3rsoft.com.pa, no a la dirección habitual. Consulte Reportar un problema de seguridad.