mirror of
https://github.com/lldap/lldap.git
synced 2026-04-25 16:25:55 +03:00
[GH-ISSUE #1269] [BUG] Pools are not dropped when shutting down #447
Labels
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lldap-lldap#447
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nitnelave on GitHub (Sep 3, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1269
Originally assigned to: @Copilot on GitHub.
Describe the bug
The DB connection pools are not dropped during clean shutdown. The DB is not aware that they are dead, and will keep them alive until TCP timeout, which can be pretty long.
Expected behavior
We need to call pool.close().await during orderly shutdown
Additional context
From sqlx docs:
Note: Drop Behavior
Due to a lack of async Drop, dropping the last Pool handle may not immediately clean up connections by itself. The connections will be dropped locally, which is sufficient for SQLite, but for client/server databases like MySQL and Postgres, that only closes the client side of the connection. The server will not know the connection is closed until potentially much later: this is usually dictated by the TCP keepalive timeout in the server settings.
Because the connection may not be cleaned up immediately on the server side, you may run into errors regarding connection limits if you are creating and dropping many pools in short order.
We recommend calling .close().await to gracefully close the pool and its connections when you are done using it. This will also wake any tasks that are waiting on an .acquire() call, so for long-lived applications it’s a good idea to call .close() during shutdown.
@nitnelave commented on GitHub (Sep 3, 2025):
@thielj FYI
@nitnelave commented on GitHub (Sep 3, 2025):
We can add the cleanup step in run_server_command in the main.rs
@thielj commented on GitHub (Sep 4, 2025):
Are you sure you don't need to implement a handler?
I've added two log statements:
Result of
docker stop lldap, sending a kill SIGTERM:PS: here's a great example, by the way ;)
github.com/lldap/lldap@775c5c716d/server/tests/common/fixture.rs (L169)PPS: Don't trust Copilot
@nitnelave commented on GitHub (Sep 4, 2025):
@thielj I'm not sure what
docker stop lldapdoes exactly, but it's not just sending a SIGTERM, since that works fine:The "Shutting down" message is one I added next to the pool close, and it prints as expected. In your case, I would expect at least "DB Cleanup stopped" to be printed during an orderly shutdown.
@nitnelave commented on GitHub (Sep 4, 2025):
And I know how far to trust Copilot, this is something I tested before, I didn't just take its word for it.
@thielj commented on GitHub (Sep 4, 2025):
Docker is sending a SIGTERM as you can see from my log.
@thielj commented on GitHub (Sep 4, 2025):
Sorry, I can't repo the correct behaviour.
I then killed the process manually, just in case. Full log follows.
This was supposed to finish with:
If you have an image somewhere that prints a shutdown message at the end of run_server_command I'm happy to test that as well.
@thielj commented on GitHub (Sep 4, 2025):
Same when running the debug build outside docker, i.e.
LLDAP_JWT_SECRET=SECRET LLDAP_LDAP_USER_PASS=SECRET12 LLDAP_VERBOSE=true target/debug/lldap run@nitnelave commented on GitHub (Sep 4, 2025):
Both logs seem correct, you have the "DB Cleanup stopped" message. In case I wasn't clear, the "Shutting down" message I was talking about is only in my local branch to make sure the correct path is taken, so you're not expected to get it.
@thielj commented on GitHub (Sep 5, 2025):
And I have messages in my local repo - as mentioned earlier today - right
before and after the code closing the pool. All I can say is that this code
isn't executed - and that I'm not surprised about that either.
On Fri, Sep 5, 2025, 00:03 nitnelave @.***> wrote:
@nitnelave commented on GitHub (Sep 5, 2025):
Are you sure you put the brakes in the right place? The pool closing happens in 2 different places
@thielj commented on GitHub (Sep 5, 2025):
Yes, they are in the right place. Now that I have removed the sqlx-rqlite dependencies that I was working on, the code is indeed executed.