starred/AdGuardHome

Fork 0

mirror of https://github.com/AdguardTeam/AdGuardHome.git synced 2026-03-04 00:01:12 -05:00

Add a function to limit the GB filesize of the query log file #3480

New issue

Open

opened 2026-03-04 03:43:05 -05:00 by deekerman · 7 comments

deekerman commented

2026-03-04 03:43:05 -05:00

Owner

Originally created by @DandelionSprout on GitHub (Feb 13, 2022).

Have a question or an idea? Please search it on our forum to make sure it was not yet asked. If you cannot find what you had in mind, please submit it here.

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

I am running the latest version (v0.108.0-b.2)
I checked the documentation and found no answer
I checked to make sure that this issue has not already been filed

Problem Description

Currently, the only method to limit the query log size's file, is by the amount of days the queries are stored. This works for 99.9% of AdGuard Home users, but can become a potential problem for those who run public servers with 100-ish weekly users. Keeping the query log time setting set to "30 days", has apparently led to an impressively large log file size of 9.2 GiB, becoming the 2nd-largest single file on my PC.

Proposed Solution

In addition to the amount of days queries can be stored, it should also be possible to set a max amount of GB (be it Linux-GB or GiB) or MB the file size can reach before the oldest entries are deleted.

Alternatives Considered

None that I'm currently aware of. Though I should probably have reduced the log days on my setup from 30 to 7 days either way.

Additional Information

The existing setting for the cache size (which I've set to 40 MB), doesn't seem to affect the query log's size.

Originally created by @DandelionSprout on GitHub (Feb 13, 2022). Have a question or an idea? Please search it [on our forum](https://github.com/AdguardTeam/AdGuardHome/discussions) to make sure it was not yet asked. If you cannot find what you had in mind, please [submit it here](https://github.com/AdguardTeam/AdGuardHome/discussions/new). ### Prerequisites Please answer the following questions for yourself before submitting an issue. **YOU MAY DELETE THE PREREQUISITES SECTION.** - [x] I am running the latest version (v0.108.0-b.2) - [x] I checked the documentation and found no answer - [x] I checked to make sure that this issue has not already been filed ### Problem Description Currently, the only method to limit the query log size's file, is by the amount of days the queries are stored. This works for 99.9% of AdGuard Home users, but can become a potential problem for those who run [public servers with 100-ish weekly users](https://github.com/DandelionSprout/adfilt/tree/master/Dandelion%20Sprout's%20Official%20DNS%20Server). Keeping the query log time setting set to "30 days", has apparently led to an impressively large log file size of 9.2 GiB, becoming the 2nd-largest single file on my PC. ![image](https://user-images.githubusercontent.com/22780683/153740413-20b616bd-e657-4ae5-8610-c3d76a7deb01.png) ### Proposed Solution In addition to the amount of days queries can be stored, it should also be possible to set a max amount of GB (be it Linux-GB or GiB) or MB the file size can reach before the oldest entries are deleted. ### Alternatives Considered None that I'm currently aware of. Though I should probably have reduced the log days on my setup from 30 to 7 days either way. ### Additional Information The existing setting for the cache size (which I've set to 40 MB), doesn't seem to affect the query log's size.

deekerman added the

feature request

label

2026-03-04 03:43:05 -05:00

deekerman commented

2026-03-04 03:43:13 -05:00

Author

Owner

@ainar-g commented on GitHub (Feb 14, 2022):

This may be partially addressed by #3404.

In addition to the amount of days queries can be stored, it should also be possible to set a max amount of GB (be it Linux-GB or GiB) or MB the file size can reach before the oldest entries are deleted.

Which of the two ways would have the priority? I.e. if my log has reached the size limit but not the duration limit, should entries still be deleted?

@ainar-g commented on GitHub (Feb 14, 2022): This may be partially addressed by #3404. > In addition to the amount of days queries can be stored, it should also be possible to set a max amount of GB (be it Linux-GB or GiB) or MB the file size can reach before the oldest entries are deleted. Which of the two ways would have the priority? I.e. if my log has reached the size limit but not the duration limit, should entries still be deleted?

deekerman commented

2026-03-04 03:43:21 -05:00

Author

Owner

@DandelionSprout commented on GitHub (Feb 14, 2022):

I.e. if my log has reached the size limit but not the duration limit, should entries still be deleted?

Correct. It'd be a "Whichever of the two that happens first" situation.

@DandelionSprout commented on GitHub (Feb 14, 2022): >I.e. if my log has reached the size limit but not the duration limit, should entries still be deleted? Correct. It'd be a "Whichever of the two that happens first" situation.

deekerman commented

2026-03-04 03:43:21 -05:00

Author

Owner

@Nahor commented on GitHub (Aug 25, 2022):

I think this issue can also be seen as a security problem. If a DNS client goes rogue, it can send a lot of requests just to fill the logs. This eventually can fill the storage device, especially on some machines like routers. Once the storage is full, things start to break down: recent queries are lost, filters don't get updated, stats are incorrect, ...

@Nahor commented on GitHub (Aug 25, 2022): I think this issue can also be seen as a security problem. If a DNS client goes rogue, it can send a lot of requests just to fill the logs. This eventually can fill the storage device, especially on some machines like routers. Once the storage is full, things start to break down: recent queries are lost, filters don't get updated, stats are incorrect, ...

deekerman commented

2026-03-04 03:43:21 -05:00

Author

Owner

@imohitkr commented on GitHub (Jun 24, 2025):

Just happened with me , the log size went up to 30 GB

@imohitkr commented on GitHub (Jun 24, 2025): Just happened with me , the log size went up to 30 GB

deekerman commented

2026-03-04 03:43:21 -05:00

Author

Owner

@sofmeright commented on GitHub (Jul 21, 2025):

+1 to this idea!

@sofmeright commented on GitHub (Jul 21, 2025): +1 to this idea!

deekerman commented

2026-03-04 03:43:21 -05:00

Author

Owner

@siliconfire commented on GitHub (Jul 29, 2025):

@siliconfire commented on GitHub (Jul 29, 2025): +1

deekerman commented

2026-03-04 03:43:21 -05:00

Author

Owner

@irvis007 commented on GitHub (Nov 20, 2025):

Just happened with me , the log size went up to 30 GB

same here ✋
logsize 30+ GB, some crap on mobile client wanted to reach malware address 7mln times in a 4 days 🌵

@irvis007 commented on GitHub (Nov 20, 2025): > Just happened with me , the log size went up to 30 GB same here ✋ logsize 30+ GB, some crap on mobile client wanted to reach malware address 7mln times in a 4 days 🌵

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/AdGuardHome#3480

No description provided.

Rows
Columns