如何调试OpenStack Dashboard(Horizon)随机自动登出问题

First, that 302 in your log is actually normal for a successful login (it redirects to the dashboard post-authentication), but the frequent auto-logouts you're seeing mean subsequent requests are failing session validation and getting redirected back to login. Let's break down the most likely causes and how to debug them step by step:

1. Check Horizon Session & Cookie Configuration #

Start with the Horizon settings—this is where most session-related issues originate:

• Open /etc/openstack-dashboard/local_settings.py
  • Verify SESSION_TIMEOUT: The default is 1800 seconds (30 minutes). If it's set to an unusually low value (like 60s), that's an obvious culprit.
  • Check SECURE_COOKIE: If you're running the dashboard over HTTP (not HTTPS), this must be False. If it's True, browsers won't send session cookies over unencrypted connections, leading to immediate logout after login.
  • Confirm SESSION_COOKIE_DOMAIN and SESSION_COOKIE_PATH: These should match your dashboard's domain (e.g., .example.com for subdomains) and path (usually /dashboard/). Mismatches here can cause cookies to be ignored.
  • If using django.contrib.sessions.backends.cache for SESSION_ENGINE, ensure the CACHES setting points to a working memcached instance (more on that below).

After making changes, restart httpd:

systemctl restart httpd

2. Verify Keystone Token Expiration #

Horizon relies on Keystone tokens for authentication—if tokens are expiring prematurely, users get logged out:

• Open /etc/keystone/keystone.conf
  • Check the [token] expiration value (default is 3600 seconds / 1 hour). If this is set too low, adjust it to a reasonable duration.
• Check Keystone logs (/var/log/keystone/keystone.log) for entries like Token revoked or Invalid token—these could indicate tokens being invalidated early due to issues like Keystone service restarts or misconfigured token persistence.
• Test token validity directly: After logging in, run openstack token issue and check the expires field to confirm it matches your configured timeout.

3. Check HTTPD & Load Balancer Session Persistence #

If you're running multiple dashboard instances behind a load balancer, or have misconfigured httpd:

• Ensure sticky sessions are enabled on your load balancer. Without this, a user's requests might bounce between instances that don't share session data, causing unexpected logouts.
• For httpd, confirm mod_wsgi is configured correctly (if using it). If running in daemon mode, make sure processes aren't being recycled too frequently (check the WSGIDaemonProcess settings in your httpd config).
• Use browser dev tools (Network tab) to inspect request/response headers:
  • When logging in, check if the sessionid cookie is set in the response.
  • On subsequent requests, verify the cookie is being sent back to the server. If not, this explains the 302 redirect to login.

4. Enable Debug Logging for Deep Dive #

Turn up logging to get more context about what's triggering the redirects:

• In Horizon's local_settings.py, set DEBUG = True (restart httpd after this). Check /var/log/horizon/horizon.log for errors like Session expired or Invalid token.
• In your httpd virtual host config for the dashboard, add LogLevel debug, then check /var/log/httpd/access_log and /var/log/httpd/error_log for detailed redirect reasons and request metadata.

5. Memcached Health Check (If Used for Sessions) #

If Horizon is using memcached to store sessions:

• Verify memcached is running: systemctl status memcached
• Test connectivity: telnet localhost 11211 then type stats—you should get a response with server stats.
• Check if memcached is low on memory: Look for evictions in the stats output. If evictions are high, memcached is dropping sessions due to insufficient memory—increase its cache size in /etc/memcached.conf.

内容的提问来源于stack exchange，提问作者Roman