#Troubleshooting

Most operational problems show up as a component that will not start, a page that returns an error, or a connection that fails. Work from the outside in: confirm the service state, read the component logs, then check the configuration the failing component depends on. This page lists the first checks and the most common causes.

#First checks

./jmsctl.sh status
./jmsctl.sh tail

Then confirm that Core is healthy:

curl -s http://127.0.0.1/api/health/

/api/health/, /koko/health/, and /lion/health/ return the component state and are also what a load balancer should check.

#Where the logs are

Component logs are written under VOLUME_DIR, /data/jumpserver by default:

Core writes jumpserver.log, gunicorn.log, drf_exception.log, and unexpected_exception.log. Read the files directly, or use Docker:

tail -f /data/jumpserver/core/data/logs/jumpserver.log
docker logs --since 30m jms_core

The detail level is controlled by LOG_LEVEL. docker logs output disappears when the container is recreated, so copy important log files aside before an upgrade.

#Common problems

#Use the audit trail

For user or administrator reports, correlate the time of the issue with the audit records in Audits > Operation logs, Login logs, and Asset sessions. The operation log shows who changed which object, while the session record shows what happened during the connection.

#Before contacting support

Collect the following in one archive:

1. Output of ./jmsctl.sh status and ./jmsctl.sh --help.
2. The JumpServer version from the UI or the installer output.
3. Core, KoKo, and web logs around the failure time.
4. The browser error, the failing URL, and the user, asset, and time involved.
5. A screenshot of the failing page, without secrets.

See the Client documentation page for connection-specific issues.

#Related topics

• Command-Line Tools
• Configuration
• Network Ports
• Backup & Restore