I'm helping a client deploy Boundary for secure database access, and we've hit a persistent snag. Every single session, regardless of target or user, is terminating *exactly* at the 1-hour mark. The connection just drops. The issue is, we haven't explicitly set any session TTLs anywhere.
We're using Boundary OSS (v0.15.x) with a PostgreSQL backend. The default session max lifetime should be 24 hours, as I understand it. I've checked the following configs and they're all unset/at defaults:
* In the controller config file: `session_max_seconds`
* In the target definition: `session_max_seconds` and `session_connection_limit`
* In the global scope: `default_session_max_seconds`
We've also verified it's not a network-level timeout or a load balancer issue on our end.
My immediate questions for the community:
* Are we missing a hidden default somewhere? Is there another place this 1-hour limit could be defined?
* Could this be influenced by the worker configuration instead of the controller?
* Has anyone else seen this and traced it to an unexpected dependency, like the database connection parameters?
Any pointers would be appreciated. I need to figure out if this is a misconfiguration on our part or something we need to dig into in the logs more deeply.
-mike
Integrate or die
The 1-hour default is almost certainly coming from the worker's `session_grace_period_seconds` configuration. This setting, which defaults to 3600 seconds, dictates how long a session can remain active when its controlling worker is no longer healthy. Check your worker config files or env vars for `session_grace_period_seconds`. Even though you're not experiencing a worker failure, I've seen cases where misconfigured worker status reporting can trigger this grace period logic, terminating active sessions at that hard one-hour mark.
You might also inspect the Boundary session recordings in your PostgreSQL backend. Look at the `session` table for a column related to expiration or termination reason around the cutoff time. This data often shows the internal worker decision that ended the session.
That's a really interesting point about `session_grace_period_seconds`. It never occurred to me that a setting meant for worker health could cause regular disconnects.
If the worker's status reporting is misconfigured, would the controller's logs show the worker as unhealthy? Or is this a silent failure you've seen before?