You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I set up a unified Bitwarden instance on Docker, using MariaDB on the host for testing purposes. However, due to other priorities, I could not create the necessary firewall rule in time for database access. The setup was left in this state for a significant period. Upon returning to the system, I found the Docker volume was nearly filled, which appears to be caused by frequent MySQL client dumps to the /app/Admin directory.
The dumps were named following a core.xxxxx pattern (where xxxxx is a number, e.g., core.27547), with each dump file approximately 74-85MB in size. These dumps had accumulated over time, reaching a size of 76GB within 7 hours. Although I recognize that a blocked database is not a supported configuration, I believe this behavior is unexpected and undesirable - it poses a significant risk as it could lead to unnecessary storage usage in a short time, even if the database were to fail for reasons other than lack of a firewall rule in a test environment.
Expected Result
I suppose it should error a few times, produce a few cores, then give up without generating continuous dumps.
Actual Result
The /app/Admin directory is continuously filled with core.xxxx files if the MySQL instance is not reachable.
Screenshots or Videos
No response
Additional Context
Here is the compose file used, minus sensitive bits:
I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
The text was updated successfully, but these errors were encountered:
I am unable to reproduce this issue, it has been escalated for further investigation. If you have more information that can help us, please add it below.
Steps To Reproduce
I set up a unified Bitwarden instance on Docker, using MariaDB on the host for testing purposes. However, due to other priorities, I could not create the necessary firewall rule in time for database access. The setup was left in this state for a significant period. Upon returning to the system, I found the Docker volume was nearly filled, which appears to be caused by frequent MySQL client dumps to the
/app/Admin
directory.The dumps were named following a
core.xxxxx
pattern (where xxxxx is a number, e.g.,core.27547
), with each dump file approximately 74-85MB in size. These dumps had accumulated over time, reaching a size of 76GB within 7 hours. Although I recognize that a blocked database is not a supported configuration, I believe this behavior is unexpected and undesirable - it poses a significant risk as it could lead to unnecessary storage usage in a short time, even if the database were to fail for reasons other than lack of a firewall rule in a test environment.Expected Result
I suppose it should error a few times, produce a few cores, then give up without generating continuous dumps.
Actual Result
The
/app/Admin
directory is continuously filled withcore.xxxx
files if the MySQL instance is not reachable.Screenshots or Videos
No response
Additional Context
Here is the compose file used, minus sensitive bits:
Githash Version
88a61fe-dirty
Environment Details
No response
Database Image
Using MariaDB 10.5.x on the host but access is blocked.
Issue-Link
#2480
Issue Tracking Info
The text was updated successfully, but these errors were encountered: