Debian 11 Supervised - Large amount of logs in /var/logs

Configuration
1

Hi,
I have been running HA Supervised on Debian for the last 6 years, and recently noted that disk space is being consumed … once I delete some files, after a few hours space is consumed back to 100% (my disk is just 128GB - and the logs are taking 57GB).

The following files are taking the most space and their content seems to be related to DNS entries:

NUC01:/var/log$ ls -lh | grep G
total 57G
-rw-r-----  1 root adm             5.7G Nov  1 10:32 daemon.log
-rw-r-----  1 root adm             2.4G Oct 27 00:01 daemon.log.1
-rw-r-----  1 root adm             5.5G Nov  1 10:32 messages
-rw-r-----  1 root adm             2.9G Oct 27 00:01 messages.1
-rw-r-----  1 root adm              16G Nov  1 10:32 syslog
-rw-r-----  1 root adm             7.8G Oct 27 00:01 syslog.1
-rw-r-----  1 root adm              11G Nov  1 10:32 user.log
-rw-r-----  1 root adm             5.4G Oct 27 00:01 user.log.1

Some examples below:
daemon.log

Nov  1 10:34:37 NUC01 dockerd[563]: time="2024-11-01T10:34:37.909731031+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.30.32.3:52580" dns-server="udp:192.168.1.212:53" error="read udp 172.30.32.3:52580->192.168.1.212:53: i/o timeout" question=";2.0.17.172.in-addr.arpa.\tIN\t PTR" spanID=ed77a78ae2150cd4 traceID=42dda78def5ad05b021c00783e8013e5
Nov  1 10:34:37 NUC01 dockerd[563]: time="2024-11-01T10:34:37.909734594+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.30.32.3:34070" dns-server="udp:192.168.1.212:53" error="read udp 172.30.32.3:34070->192.168.1.212:53: i/o timeout" question=";2.0.17.172.in-addr.arpa.\tIN\t PTR" spanID=32f123d83452a7e2 traceID=ed241790a05f2490f8242bf6fac69e4e
Nov  1 10:34:38 NUC01 systemd[1]: run-docker-runtime\x2drunc-moby-e10d5a13318fb18de8bee99006c1aa8ac206d184c9d6ec73fe053417244a1048-runc.EtaW6q.mount: Succeeded.
Nov  1 10:34:38 NUC01 systemd[435380]: run-docker-runtime\x2drunc-moby-e10d5a13318fb18de8bee99006c1aa8ac206d184c9d6ec73fe053417244a1048-runc.EtaW6q.mount: Succeeded.
Nov  1 10:34:38 NUC01 dockerd[563]: time="2024-11-01T10:34:38.061193916+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.30.32.3:55409" dns-server="udp:192.168.1.212:53" error="read udp 172.30.32.3:55409->192.168.1.212:53: i/o timeout" question=";2.0.17.172.in-addr.arpa.\tIN\t PTR" spanID=ec6b9e4f605b4e36 traceID=476fd06dc6322fa55a66c2f694efdf00
Nov  1 10:34:38 NUC01 dockerd[563]: time="2024-11-01T10:34:38.118968202+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.30.32.3:32807" dns-server="udp:192.168.1.212:53" error="read udp 172.30.32.3:32807->192.168.1.212:53: i/o timeout" question=";2.0.17.172.in-addr.arpa.\tIN\t PTR" spanID=cf63d4787cc74897 traceID=330d79266800c338bdab78bb84a9ae73

messages

Nov  1 10:36:59 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:55729 - 28537 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.02342137s
Nov  1 10:36:59 NUC01 hassio_dns[563]: [INFO] 172.30.32.1:55804 - 56183 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 2.02428919s
Nov  1 10:36:59 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:56035 - 41660 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.028600628s
Nov  1 10:36:59 NUC01 hassio_dns[563]: [INFO] 172.30.32.1:35667 - 39464 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 2.029865481s
Nov  1 10:36:59 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:37624 - 58619 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.031240252s
Nov  1 10:36:59 NUC01 hassio_dns[563]: [INFO] 172.30.32.1:52801 - 6503 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 2.031748813s
Nov  1 10:36:59 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:55729 - 32469 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.023528745s

syslog

Nov  1 10:37:53 NUC01 hassio_dns[563]: [INFO] 172.30.32.1:52810 - 23666 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 2.0419139s
Nov  1 10:37:53 NUC01 dockerd[563]: time="2024-11-01T10:37:53.563484280+01:00" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:172.30.32.3:41072" dns-server="udp:192.168.1.212:53" error="read udp 172.30.32.3:41072->192.168.1.212:53: i/o timeout" question=";2.0.17.172.in-addr.arpa.\tIN\t PTR" spanID=7cdaa48970bbe5c8 traceID=388e511366c7f2ba685817fab5db7016
Nov  1 10:37:53 NUC01 addon_a0d7b954_adguard[563]: 2024/11/01 10:37:53.567514 ERROR response received addr=172.30.32.3:53 proto=udp status="exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:41296->172.30.32.3:53: i/o timeout"
Nov  1 10:37:53 NUC01 addon_a0d7b954_adguard[563]: 2024/11/01 10:37:53.567564 [error] dnsproxy: exchange failed upstream=172.30.32.3:53 question=";2.0.17.172.in-addr.arpa.\tIN\t PTR" duration=2.001450339s err="exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:41296->172.30.32.3:53: i/o timeout"
Nov  1 10:37:53 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:55936 - 43021 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.028424062s
Nov  1 10:37:53 NUC01 hassio_dns[563]: [INFO] 172.30.32.1:40956 - 33286 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 2.030096658s

user.log

Nov  1 10:38:35 NUC01 addon_a0d7b954_adguard[563]: 2024/11/01 10:38:35.214712 [error] dnsproxy: exchange failed upstream=172.30.32.3:53 question=";2.0.17.172.in-addr.arpa.\tIN\t PTR" duration=2.002223844s err="exchanging with 172.30.32.3:53 over udp: read udp 172.30.32.1:54524->172.30.32.3:53: i/o timeout"
Nov  1 10:38:35 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:47935 - 9724 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.024956814s
Nov  1 10:38:35 NUC01 hassio_dns[563]: [INFO] 172.30.32.1:59298 - 65460 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 2.026179857s
Nov  1 10:38:35 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:41416 - 19696 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.031213401s
Nov  1 10:38:35 NUC01 hassio_dns[563]: [INFO] 172.30.32.1:57566 - 31512 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 2.03220952s
Nov  1 10:38:35 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:43366 - 27079 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.037723336s
Nov  1 10:38:35 NUC01 hassio_dns[563]: [INFO] 172.30.32.1:41002 - 41232 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 2.038625289s
Nov  1 10:38:35 NUC01 hassio_dns[563]: [INFO] 127.0.0.1:40942 - 26192 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.039483721s

Also in the configuration.yaml I have the following:

logger:
  default: error
  logs:
    homeassistant.core: warning 
    homeassistant.components.influxdb: warning
    homeassistant.components.rest: warning

I think this started recently because the hard disk went full this week, if it has been going like this before most probably I would have noticed.

Any ideas how to go around this?

2

It looks like the DNS service at 192.168.1.212 is not responding, so start with looking into that.

3

agree but 192.168.1.212 is the IP of the HA host (same machine on which the logs are saved) … any idea how I can troubleshoot this issue?

4

@WallyR updated the DNS allocation from the modem … now DHCP is allocating the IP address of the modem instead of that of the NUC (I use ad-guard running on the NUC). Not sure why but logs now are not being overloaded.

Is it safe to delete those files having .1 in the filename to make some space?

-rw-r-----  1 root adm             5.8G Nov  1 13:52 daemon.log
-rw-r-----  1 root adm             2.4G Oct 27 00:01 daemon.log.1
-rw-r-----  1 root adm             5.7G Nov  1 13:51 messages
-rw-r-----  1 root adm             2.9G Oct 27 00:01 messages.1
-rw-r-----  1 root adm              17G Nov  1 13:52 syslog
-rw-r-----  1 root adm             7.8G Oct 27 00:01 syslog.1
-rw-r-----  1 root adm              11G Nov  1 13:51 user.log
-rw-r-----  1 root adm             5.4G Oct 27 00:01 user.log.1
5

.1 is logs files from the previous run and those without is for the current run.
It is safe to delete them, but on next restart those with .1 will be deleted and those without will then be renamed to .1s, so new log files without .1 can be created.

1 Like
6

Looks like the access to adguard is being blocked then.
You need to look into your firewall then or other stuff that can block.
Since it is a Supervised installation, then it is impossible for me to guess the setup and besides that it is also unsupported, since Debian 12 is a requirement.

7

I am not using a firewall … maybe internal routing through docker is not in place?

yes i am aware of that, need to find sometime to take some backups and upgrade.

8

Consider HAOS instead of Supervised, it has every bell and whistle that Supervised has (HACS, Add-Ons, etc.) + you can more easily use the Visual Studio Code editor. If you want to use the host for something other than HA as well, then you can get a very inexpensive NUC which are cheaper than the RPI5’s and vastly more powerful, and use free Proxmox and run HAOS on a VM.

Also, you can restore a Supervised Backup directly onto an HAOS instance, so even the migration is painless!

Was there a specific reason for HA Supervised (I was like you but made the leap)?

9

I need to migrate to Proxmox when I have some time. I went to supervised version just to be able to run some cronjobs, and to have access to Linux. I have been running it for more than 5 years now and never had any issues. Most probably the issue I am having now was present even before, just noticed it now since the HD got to 100%

10

Hi mouthpiec,

Debian 11 has to be updated, too, that’s out of date for Supervised.
Plus there are a number of of tweaks that have to be installed for that to work right, and I think you need Python update.

Lot’s of problems, and the issue you list in the question is only a tiny part of them.

Not to mention Supervised is supported at the same level as core. If you are running it, you have to know what you are doing, and there are not a lot of answers available elsewhere if you do.
Back it up, install HAOS or container version, and you get all kinds of helpers.

11

Instead of fixing it, and then you are stuck with the old setup, it might take you less time to back it up, download a HAOS image, just start it on a VM, then restore from your Supervised backup - onto that running HAOS instance. When I migrated, it took me less than an hour. I have ~400 automations, >600 entities and something like ~300 devices - and once the restore was completed, I had nothing to fix - I work with technology for a living and that is one of the few times I have been so astonished.

1 Like
12

this is impressive … when I migrated from Pi to NUC it was seamless too.
I think I need to upgrade the HD on the NUC, might as well make install Proxmox and migrate onto it (and keep the current HD as backup just in case I encounter issues)

13

quick question … can I install proxmos on debian? or proxmos needs to replace the debian OS?

14

Proxmox is its own OS, so it will replace Debian, but there are hypervisors for Debian too.
Qemu is such one among many and I think Proxmox is actually using that too.
Proxmox just provide a stripped down lean OS with a nice web interface for administration.
For HA I do not think there will be any difference between the two setups, other than Debian requiring some extra resource draw on the hardware.

1 Like
15

thanks for the info. asking to check if it is possible to try it out before installing it