Hi, I’m new to DietPi, coming from Raspbian Lite. Limited knowledge on Linux etc. so please excuse my n00b questions. 
I see there is a monthly cron job for auto-update of the root.hints file for Unbound. But there is no command to restart the Unbound service afterwards. Don’t I need to restart it after root.hints update? every guide I’ve read so far says I should do a sudo restart on the Unbound service?
On RAMlog, is there a max RAM usage limit for it? I found a post from 2015 mentioning there is a 20MB limit, is that still the case?
Also I seem to remember a post somewhere mentioning RAMlog saves logs to disk after software installs/updates? I assume that’s for RAMlog #2 and FullLog right?
When I check the status of RAMlog service it says:
Active: active (exited) since Sun 2021-11-21
Why does it say (exited)? Also why is the timestamp Nov 21 when I only installed DietPi on Dec 04?
Thanks in advance for any answers. And thank you to the DietPi team for this wonderful distro. Way less daunting than I expected. 
Hi 
,
yes you are right, for the new root.hints to take effect an Unbound restart is required. However, those are usually valid much longer than a month, so as long as there are no actual DNS resolution issues, it’s fine to leave Unbound running and have it using the new root.hints as fast as maintenance tasks or a server restart imply an Unbound service restart anyway.
DietPi-RAMlog by default has a maximum size of 50 MiB. You can check it via df -h /tmp or grep ‘/var/log’ /etc/fstab and you can change it in /etc/fstab as well, e.g. replacing the “50M” in the related line with “20M” or “100M” for 20 MiB respectively 100 MiB.
DietPi-RAMlog stores the empty file and directory structure to disk on shutdown:
ls -l /var/tmp/dietpi/logs/dietpi-ramlog_store
and restores this on bootup. This is required so that log files and directories with correct UNIX permissions are present, else all non-root services which do file logging would fail to start up. But it does not include the actual log file content. For this you indeed would need to use the “RAMlog #2” option, in which case the content of the log files is appended in /root/logfile_storage, before the files are cleared on hourly basis.
The DietPi-RAMlog service shows “exited” as the actual systemd services does only the mentioned storing and restoring of the empty file/directory structure to/from disk on shutdown/bootup, while the RAM disk itself is a simple “tmpfs” mount, managed completely by systemd.
The timestamp mismatch is likely because the network time sync was not yet done at the early boot stage when the RAMlog service starts (“long” before network is configured). So you basically see the timestamp of the image generation 
. When you check journalctl you should see boot/kernel logs, then first systemd logs, with old timestamps, and then the network time sync with a jump to the new/correct time stamp. And after a reboot it should show much closer timestamps.
I hope I caught and answered all questions.
Thank you so much for the answers!
Just a little confused about this part still:
By “maintenance tasks”, you mean a user-initiated system task like “apt update” or “apt upgrade”, and not some automated background maintenance tasks run by the system, is that correct?
Thanks.
it’s more like a reboot once you update kernel packages or similar. Usually there is no automated task to restart unbound.
Thank you very much to you both for the answers.
Greatly appreciated!