I've had this happen a couple of times this month, where my network stops responding and when I check pihole status it says DNS not listening - doing a pihole restartdns then puts it back up and running.
Today I checked the syslog and found some exceptions and then the memory issues below.
As doing a restartdns seems to bring the system back up, is there anything I can do to make that automatic? It happened today while I was out of the house and so I wasn't too popular with those left in the house
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
This is a 256 MiB RAM Raspberry Pi 1 model? I guess when some maintenance is done via cron job, like Pi-hole gravity update, this can be too close. You may be able to uninstall/disable some unneeded background processes/services and reduce RAM usage also during maintenance by looking at cron jobs, but easiest is to raise the swap file size.
Is the swap file locate on the SD card currently, and if so, are you able to attach a USB flash drive for it? That would be much better to reduce wear on the SD card and for performance.
yeah it is just an old 256 MiB Pi1 B. swap file must be on the SD card as I have no USB attached, but I must have some old USBs hanging around I could try out
You have a MariaDB server which takes by far most memory. It is not required for Pi-hole. There was concurrent PHP session clean and APT processes, so looks like some systemd timer and (daily?) cron job were just executed which may have caused the peak over steady memory consumption, causing the OOM killer to take action.
All default systemd timers are usually very reasonable, also the PHP session cleaning simply makes sense (when native PHP sessions are used) and does not consume much memory. Though, Pi-hole does not use PHP sessions, AFAIK (?), hence it could be disabled:
systemctl disable --now phpsessionclean.timer
EDIT: Pi-hole DOES make use of native PHP sessions, hence this timer should stay active! Else session files will fill disk or RAM (depending on where stored, usually in /var/lib/php/sessions) unlimited.
The APT processes likely come from unattended-upgrades, updating package cache and in case applying security upgrades:
dpkg -l unattended-upgrades
This is quite useful for a server, so I wouldn't disable it, as long as you do not apply APT upgrades manually on a regular basis.
I'd really check whether you require the MariaDB server at all. If you do, increase the swap file size so that steady memory consumption (excluding systemd timers and cron jobs) is around 50% of total memory, to have sufficient buffer. For this, lets first check how it is implemented:
ah, now I remember installing a DB a good while ago just to have a play with - its not in active use but I guess it still runs in the background. Maybe stopping that is enough, but here is the other output mentioned above...
$ systemctl --no-pager --full -a list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Sun 2022-01-23 19:39:00 GMT 17min left Sun 2022-01-23 19:09:01 GMT 12min ago phpsessionclean.timer phpsessionclean.service
Mon 2022-01-24 00:00:00 GMT 4h 38min left Sun 2022-01-23 00:00:02 GMT 19h ago logrotate.timer logrotate.service
Mon 2022-01-24 00:00:00 GMT 4h 38min left Sun 2022-01-23 00:00:02 GMT 19h ago man-db.timer man-db.service
Mon 2022-01-24 02:15:26 GMT 6h left Sun 2022-01-23 10:40:26 GMT 8h ago apt-daily.timer apt-daily.service
Mon 2022-01-24 06:31:35 GMT 11h left Sun 2022-01-23 06:07:04 GMT 13h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Mon 2022-01-24 09:54:16 GMT 14h left Sun 2022-01-23 09:54:16 GMT 9h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
$ dpkg -l unattended-upgrades
dpkg-query: no packages found matching unattended-upgrades
$ dpkg -l dphys-swapfile
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii dphys-swapfile 20100506-5 all Autogenerate and use a swap file
No unattended-upgrades, so the apt-daily-upgrade timer/service does nothing, but apt-daily timer/service still updates the APT list/cache, which very likely is the reason for the APT processes shown in OOM killer log.
It shouldn't be required when disabling MariaDB, but in case, you can change the swap file size via /etc/dphys-swapfile and then apply via:
For a Pi, you can even change the memory split if dont use any graphical desktop features etc:
gpu_mem
Specifies how much memory, in megabytes, to reserve for the exclusive use of the GPU: the remaining memory is allocated to the ARM CPU for use by the OS. For Pis with less than 1GB of memory, the default is 64; for Pis with 1GB or more of memory the default is 76.
Run sudo raspi-config and select:
Performance Options --> GPU Memory
I've just just now as an experiment changed it into 16MB.
Before:
pi@ph5a:~ $ free -h
total used free shared buff/cache available
Mem: 176Mi 38Mi 51Mi 2.0Mi 86Mi 88Mi
Swap: 99Mi 41Mi 58Mi
After:
pi@ph5b:~ $ free -h
total used free shared buff/cache available
Mem: 477Mi 43Mi 317Mi 3.0Mi 116Mi 381Mi
Swap: 99Mi 0B 99Mi
Wrong Pi, below is correct one:
pi@ph5a:~ $ free -h
total used free shared buff/cache available
Mem: 224Mi 38Mi 56Mi 5.0Mi 129Mi 132Mi
Swap: 99Mi 0B 99Mi
: