# Vault agent max TTL exceeded warning **URL:** \ **Category:** Vault\ **Tags:** k8s\ **Created:** [March 25, 2022, 4:04pm UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578 "2022-03-25T16:04:53Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![mamjong](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/mamjong/32/26988_2.png) [@mamjong](https://discuss.hashicorp.com/u/mamjong)\ **Post date:** [March 25, 2022, 4:04pm UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578/1 "2022-03-25T16:04:54Z")
Hi, We are using dynamic secrets for database credentials, which the vault agent should and seems to fully manage correctly. However, the vault agent logs the following warning every once in a while: ```auto 2022-03-17T06:52:00.645Z [WARN] vault.read(database/creds/profileservice): TTL of "24h" exceeded the effective max_ttl of "3h49m49s"; TTL value is capped accordingly 2022-03-17T06:52:00.645Z [WARN] vault.read(database/creds/profileservice): renewer done (maybe the lease expired) 2022-03-17T06:52:10.802Z [INFO] (runner) rendered "(dynamic)" => "/vault/secrets/mysql.conf" ``` As far as I understand, the vault agent should renew its lease on the database secret every once in a while (based on default TTL), but at some point the default TTL of 24h would exceed the max TTL of the issued credentials and then this warning occurs. The vault agent seems to handle this fine and request a new set of credentials. However, since this is a warning I was wondering if this is something I can fix, and how to fix it. I can’t seem to find anything about this warning in the docs. Thanks in advance! ---
**Author:** ![jeffsanicola](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/jeffsanicola/32/18651_2.png) [@jeffsanicola](https://discuss.hashicorp.com/u/jeffsanicola)\ **Post date:** [March 25, 2022, 5:43pm UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578/2 "2022-03-25T17:43:19Z")
Are the TTLs set correctly on the role itself within Vault? Sounds like `default_ttl` might be set to `24h` and `max_ttl` set to `4h`. > **[Database - Secrets Engines - HTTP API | Vault by HashiCorp](https://www.vaultproject.io/api-docs/secret/databases#create-role)** > > Top page for database secrets engine information Otherwise the global `max_lease_ttl` might be conflicting. > **[Server Configuration | Vault by HashiCorp](https://www.vaultproject.io/docs/configuration#max_lease_ttl)** > > Vault server configuration reference. ---
**Author:** ![mamjong](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/mamjong/32/26988_2.png) [@mamjong](https://discuss.hashicorp.com/u/mamjong)\ **Post date:** [March 28, 2022, 7:54am UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578/3 "2022-03-28T07:54:04Z")
The default and max TTL seem to be fine. From the database secret role in the vault UI: ![image](https://global.discourse-cdn.com/hashicorp/original/3X/9/7/975645c5cfb53923a31b91b277afee42c2f0d261.png) We also do not set the global setting, so that should default to 768h I believe? However, if I navigate to the configuration of the database secret engine I do see the following TTL: ![image](https://global.discourse-cdn.com/hashicorp/original/3X/2/3/23b01cee70d5af82516d9bcbb75e014bf48173b8.png) I’m not sure if that’s correct. ---
**Author:** ![jeffsanicola](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/jeffsanicola/32/18651_2.png) [@jeffsanicola](https://discuss.hashicorp.com/u/jeffsanicola)\ **Post date:** [March 28, 2022, 12:06pm UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578/4 "2022-03-28T12:06:56Z")
My understanding is that if the Default/Max lease TTL is set to 0 it’ll use the next higher level’s TTL. So if a role doesn’t have TTLs defined it’ll use the secret engine config configured TTLs. If the secret engine config doesn’t have TTLs specified it’ll use the global. With that said, secret leases are also, generally, dependent on your auth token’s TTL - when your auth TTL expires your secret lease will be revoked. What are your auth role TTL settings? ---
**Author:** ![mamjong](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/mamjong/32/26988_2.png) [@mamjong](https://discuss.hashicorp.com/u/mamjong)\ **Post date:** [March 28, 2022, 12:27pm UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578/5 "2022-03-28T12:27:49Z")
The configuration of the Kubernetes auth method which we use has both **Default Lease TTL** and **Max Lease TTL** set to 0. Under a specific role within that auth method, the **Generated Token’s Explicit Maximum TTL** , **Maximum Uses of Generated Tokens** , **Generated Token’s Period** and **Generated Token’s Initial TTL** are all set to 0. Only the **Generated Token’s Maximum TTL** is set to 1800000. ---
**Author:** ![jeffsanicola](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/jeffsanicola/32/18651_2.png) [@jeffsanicola](https://discuss.hashicorp.com/u/jeffsanicola)\ **Post date:** [March 30, 2022, 12:21pm UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578/6 "2022-03-30T12:21:30Z")
Interesting. I’m not sure then, unless there is something in the agent config or its own code. Perhaps someone most familiar with the agent could offer some insight. ---
**Author:** ![TJM](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/tjm/32/27273_2.png) [@TJM](https://discuss.hashicorp.com/u/TJM)\ **Post date:** [April 7, 2022, 3:13pm UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578/7 "2022-04-07T15:13:54Z")
We are seeing the same thing, in our case, it is the “GCP” Secrets engine. We have seen problems where the application team says the token is expired, so we created an “excessively” low TTL/Max to test… ```auto [tmcneely@local ~]$ vault read cwow/test-denodo-ttl/np/gcp/config Key Value --- ----- max_ttl 1h ttl 15m ``` We are seeing that the Vault agent just seems to blindly refresh the lease, it doesn’t seem to pay much heed to “max\_ttl”. This happens every hour (max\_ttl), where it is like “OMG, the lease is gone!? Get a new one!?” This is not the expected behavior. It should be renewing the lease at like 80-90% of its life, and when it reaches max\_ttl, it should get a new lease, right? ```auto Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:10.817-0700 [INFO] cache: received request: method=PUT path=/v1/sys/leases/renew Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:10.817-0700 [INFO] cache.apiproxy: forwarding request: method=PUT path=/v1/sys/leases/renew Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:10.972-0700 [WARN] vault.read(cwow/test-denodo-ttl/np/gcp/key/denodo-spanner-sa-test-denodo-ttl-6208): failed to renew: Error making API request. Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: URL: PUT http://127.0.0.1:8200/v1/sys/leases/renew Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: Code: 400. Errors: Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: * lease not found Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:10.972-0700 [WARN] vault.read(cwow/test-denodo-ttl/np/gcp/key/denodo-spanner-sa-test-denodo-ttl-6208): renewer done (maybe the lease expired) Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:10.972-0700 [INFO] cache: received request: method=GET path=/v1/cwow/test-denodo-ttl/np/gcp/key/denodo-spanner-sa-test-denodo-ttl-6208 Apr 07 06:16:10 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:10.972-0700 [INFO] cache.apiproxy: forwarding request: method=GET path=/v1/cwow/test-denodo-ttl/np/gcp/key/denodo-spanner-sa-test-denodo-ttl-6208 Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.446-0700 [INFO] cache: received request: method=PUT path=/v1/sys/leases/renew Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.446-0700 [INFO] cache.apiproxy: forwarding request: method=PUT path=/v1/sys/leases/renew Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.447-0700 [INFO] (runner) rendered "/var/lib/vault/template.ctmpl" => "/var/lib/vault/vault_agent.json" Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.447-0700 [INFO] (runner) executing command "/var/lib/vault/write_secret.sh" from "/var/lib/vault/template.ctmpl" => "/var/lib/vault/vault_agent.json" Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.447-0700 [INFO] (child) spawning: /var/lib/vault/write_secret.sh Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.482-0700 [INFO] cache: received request: method=GET path=/v1/sys/internal/ui/mounts/cwow/np/secret/denodo/denodo-spanner-sa-test-denodo-ttl-6208-b Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.482-0700 [INFO] cache.apiproxy: forwarding request: method=GET path=/v1/sys/internal/ui/mounts/cwow/np/secret/denodo/denodo-spanner-sa-test-denodo-ttl-6208-b Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.611-0700 [INFO] cache: received request: method=PUT path=/v1/cwow/np/secret/data/denodo/denodo-spanner-sa-test-denodo-ttl-6208-b Apr 07 06:16:11 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:16:11.611-0700 [INFO] cache.apiproxy: forwarding request: method=PUT path=/v1/cwow/np/secret/data/denodo/denodo-spanner-sa-test-denodo-ttl-6208-b Apr 07 06:26:50 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:26:50.427-0700 [INFO] cache: received request: method=PUT path=/v1/sys/leases/renew Apr 07 06:37:29 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:37:29.095-0700 [INFO] cache: received request: method=PUT path=/v1/sys/leases/renew Apr 07 06:48:07 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:48:07.762-0700 [INFO] cache: received request: method=PUT path=/v1/sys/leases/renew Apr 07 06:58:46 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T06:58:46.427-0700 [INFO] cache: received request: method=PUT path=/v1/sys/leases/renew Apr 07 07:09:25 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T07:09:25.093-0700 [INFO] cache: received request: method=PUT path=/v1/sys/leases/renew Apr 07 07:20:03 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T07:20:03.761-0700 [INFO] cache: received request: method=PUT path=/v1/sys/leases/renew Apr 07 07:20:03 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T07:20:03.761-0700 [INFO] cache.apiproxy: forwarding request: method=PUT path=/v1/sys/leases/renew Apr 07 07:20:03 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T07:20:03.908-0700 [WARN] vault.read(cwow/test-denodo-ttl/np/gcp/key/denodo-spanner-sa-test-denodo-ttl-6208): failed to renew: Error making API request. Apr 07 07:20:03 sea1l5ddvsa29.example.com vault[21958]: URL: PUT http://127.0.0.1:8200/v1/sys/leases/renew Apr 07 07:20:03 sea1l5ddvsa29.example.com vault[21958]: Code: 400. Errors: Apr 07 07:20:03 sea1l5ddvsa29.example.com vault[21958]: * lease not found Apr 07 07:20:03 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T07:20:03.908-0700 [WARN] vault.read(cwow/test-denodo-ttl/np/gcp/key/denodo-spanner-sa-test-denodo-ttl-6208): renewer done (maybe the lease expired) Apr 07 07:20:03 sea1l5ddvsa29.example.com vault[21958]: 2022-04-07T07:20:03.908-0700 [INFO] cache: received request: method=GET path=/v1/cwow/test-denodo-ttl/np/gcp/key/denodo-spanner-sa-test-denodo-ttl-6208 ``` ---
**Author:** ![TJM](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/tjm/32/27273_2.png) [@TJM](https://discuss.hashicorp.com/u/TJM)\ **Post date:** [April 7, 2022, 9:29pm UTC](https://discuss.hashicorp.com/t/vault-agent-max-ttl-exceeded-warning/37578/8 "2022-04-07T21:29:20Z")
Interesting… while looking at this, it mostly follows the pattern above, but every once in a while it does this: > … YIKES! - It does seem to be “aware” that there is a max\_ttl - It beats the heck out of the vault server (retry over and over and over) instead of having a retry loop (this is a common vault agent issue) - It appears to have gotten a new lease before it expired (which is desirable) … but only this one time