Changed Ramlog from #1 to #2 and Sonarr, Lidarr, Radarr services no longer start

Troubleshooting
1

I thought about going to sonarr reddit with this but I thought i’d start here as it was a dietpi change I made that seemed to cause this. Any help is VERY appreciated.

So I changed my logging “Dietpi-Ramlog #1”, to #2 the intent was to be able to refer to older log files as I was having some unexpected lock ups (Server unresponsive to pings remotely) After hard resetting I never seemed to have any log files to refer to.

  • DietPi-RAMlog #1 (Max performance): Mounts /var/log to RAM, reducing │
    │ filesystem IO. Logfiles are cleared every hour. Does NOT save logfiles to │
    │ disk.
    │ - DietPi-RAMlog #2: Same as #1, with the added feature of saving logfile │
    │ contents to disk (/root/logfile_storage/*), before being cleared.

I did this, it succeeded, required reboot.

After reboot the Sonarr service will not load. Coincidentally neither will Lidarr or Radarr services.

When I look this is the message I get when it attempts to start:
sonarr.service - Sonarr Daemon (DietPi)

│ Loaded: loaded (/etc/systemd/system/sonarr.service; disabled; vendor
│ preset: enabled)
│ Active: failed (Result: exit-code) since Sat 2020-10-10 12:25:29 PDT; 7s
│ ago
│ Process: 1946 ExecStart=/usr/bin/mono -O=-aot /opt/NzbDrone/NzbDrone.exe
│ -nobrowser -data=/mnt/dietpi_userdata/sonarr (code=exited,
│ status=226/NAMESPACE)
│ Main PID: 1946 (code=exited, status=226/NAMESPACE)

I have no idea what this status means.
Do any DietPi guru’s have any idea what might be borked here based on this, or what status=226/NAMESPACE means?

Appreciate any assistance. I’m still pretty novice to the whole thing.

I would like to avoid a full reinstall of Sonarr/Lidarr/Radarr as I just got them configured to my liking. (no backups, which I should remedy soon)

I went to /mnt/dietpi_userdata/sonarr and noticed:
https://drive.google.com/file/d/1sX2K4xyf13aiC9LAc7zlh9g4zRTPCdTq/view?usp=sharing
Saw the exclamations next to the symbolic links and took a look at the properties of “logs” and see the target is /var/log/sonarr.

I don’t know what a symbolic link is but I’m guessing these are like shortcuts and the exclamation indicates a problem? So I have looked at /var/log/

there is no /sonarr or /lidarr or /radarr.

Pretty sure those were there before the log file change I made, but I could be wrong!

Are these missing directories the problem do you think? Does changing the logging delete /var/log/ subdirectories that aren’t DietPi related?

Thanks for your help!

2

Ok. So it wasn’t directories missing. It was just the files.

I created a “sonarr” “lidarr” “radarr” file in /var/log and was able to start the services and everything is functioning again.

Any recommendations of something I should change maybe to avoid this in the future? Or any tips in general. Always open for constructive criticism.

Thanks again!

3

Hi,

many thanks for your report. Indeed it seems switching the ram log leads Sonarr to fail. Looks like there is something wrong during changing the log mode. Let me open an issue at Github for this.

https://github.com/MichaIng/DietPi/issues/3819

4

Many thanks for reporting. Resolved for DietPi v6.33: https://github.com/MichaIng/DietPi/issues/3819#issuecomment-706704274

5

Hi djashdj

I just double checked the original setting and you would need to create directories for Sonarr, Lidarr, Radarr within /var/log/. Just creating files might fit to start the service, but could lead to issues on future operation. This is how it should looks like.

root@DietPi3:~# ls -la /var/log/|grep arr
drwxr-xr-x  2 bazarr dietpi   60 Oct 11 22:15 bazarr
drwxr-xr-x  2 lidarr dietpi  120 Oct 11 22:17 lidarr
drwxr-xr-x  2 radarr dietpi   80 Oct 11 22:17 radarr
drwxr-xr-x  2 sonarr dietpi  120 Oct 11 22:17 sonarr
root@DietPi3:~#

i highly recommend to adjust your system this way.

6

/boot/dietpi/func/dietpi-ramlog 0 or a reboot is really all that should be required. The logs (and directory structure) are not lost, they were just not copied back from disk to RAMdisk when RAMlog was already enabled before (switching from #1 to #2 or the other way round), but stored in /var/tmp/dietpi/logs/dietpi-ramlog_store/.

7

Good stuff thank you both.

You were absolutely correct on creating the directories. With out that it did fail on reboot. I created the directories (empty) with appropriate permissions and restarted the services and they started and creating their own appropriate log files in the directories. So all is good there I believe. Thank you.

Question on reviewing DietPi log files:

I seem to be having an issue where my Pi locks up seemingly randomly. I think it’s a CPU overheating issue but I’m not sure. I turned up the logging so that I would be able to view them after it locks up and crashes.

When it locks up and becomes unresponsive to the network, the fan is still spinning leading me to believe the system may still be functioning to some degree. Since I can’t connect to it remotely I unplug it and plug it back in. Is there a possibility I would lose the last hour of logging if I do that? I’m trying to capture the last recorded items just before the apparent lockup. So if I lose log files with in the last hour before the lockup I’ll probably have to change my logging again correct?

The log files I would want to look at for additional information on what might be causing the lock up would be located in?
/root/logfile_storage ???
and would be called lastlog ? What do I use to view this file? I tried VIM and leafpad but neither open the document in a readable format.

Thanks for your help and if this too much topic drift I can ask this somewhere more appropriate.

Thanks!

8

If you want to see crash logs, you need to switch to full logging. #2 only stores the logs to disk (yes the path is correct) once an hour, so likely when it crashes the important logs are missing. /var/log/syslog and /var/log/kern.log should be the most important ones then.

Btw another solution I like much more and want to use to replace rsyslog+logrotate based permanent logging:
Switch to logging mode 0 none/custom
mkdir /var/log/journal
When this directory is present, the native systemd-journald that is anyway always running, logs permanently to this location. Much less overhead compared to rsyslog + logrotate. Now when the system crashes you can check journalctl and have all logs combined, filter- and sort-able.

9

Ok great! I’ll up the logging and do as you mentioned and then wait for the crash and see what I can find out. Thanks for the good tips and assistance.

10

btw it’s not a surprise that your fan is still running even if your system crashed. as long as there is power on your device, the fill will continue spinning. Similar would happen if you run poweroff command, your fan would not stop until you remove power :slight_smile: