I had a strange experience with the DietPi Log Setup that I thought might be interesting for the devs to know. So here’s what has happened:
I have run DietPi with DietPi Ramlog #2 (hourly backup, then clean) since I had the system installed. Some time ago I installed OpenVPN using PiVPN. During installation I noticed that rsyslog was also installed, as it is used by OpenVPN (PiVPN sets the syslog option in server.conf and creates a syslog conf for OpenVPN). Now that my system is running without problems for quite some time, I wanted to change the Ramlog to option #1 (no backup, just clean). So I changed that option in dietpi-software and wanted to save it. However, I got a message that rsyslog would be uninstalled if I proceed. First I was unsure and cancelled, but this left my Ramlog unchanged at #2. So I tried again, this time going ahead with the process and hoping that everything works out okay And indeed, rsyslog was purged and even gave a message that the conf directory (/etc/syslogd ?) could not be removed (because of the openvpn.conf file inside). There seemed to be no problem for OpenVPN with rsyslog missing, but I changed the config to log_append just to be save.
I’m sure this kind of behaviour is not intended, and might even cause problems in some cases. I also tried to find out what caused rsyslog to be installed in the first place, but could not find it mentioned anywhere. I had a quick look at dietpi-software and the PiVPN setup script, and did not find it there, and it is also not listed in the dependencies for the openvpn package, but I’m not to familiar with the APT tools to be sure about that.
Yeah there are some cases where rsyslog, respectively a certain contained log file, is used by software titles. Not sure if/why this is the case with PiVPN, but it should be possible to configure it using systemd-journald instead, so it does not interfere with DietPi-RAMlog.
Otherwise if rsyslog is really required, there are two possibilities how we should handle it:
Either inform user that logging mode will be switched to full logging, since rsyslog is required by the software that is attempted to install.
Rare/unlikely case: If rsyslog is required, but hourly clean and non-persistent logs are okay, install rsyslog but keep RAMlog.
And when switching logging mode, it should be checked if a software title is installed that requires rsyslog, before purging it. This is easy since logging mode is switched via dietpi-software as well and rsyslog requirement is saved in a script wide array, so easy to check.
Basically, thats what happenend here. Unintentionally. rsyslog got installed, but RAMlog was never disabled. So it logged to /var/log and got copied/cleaned every hour.
And when switching logging mode, it should be checked if a software title is installed that requires rsyslog, before purging it. This is easy since logging mode is switched via > dietpi-software > as well and rsyslog requirement is saved in a script wide array, so easy to check.
That’s probably the best solution. And I wondered, that there was no warning or info from apt, assuming that it was somehow installed as dependency. But as I said, I’m not too familiar with the apt tools and I could not figure out, why rsyslog was installed.