cenzar

Support for Docker templates Plantuml Project Website: https://plantuml.com/ DockerHub: https://hub.docker.com/r/plantuml/plantuml-server/ Github: https://github.com/plantuml/plantuml-server Be sure to check the application's documentation for answers to application-specific errors. This thread is intended for discussing issues related to the Docker template and running the container on Unraid. Post any questions or issues relating to Docker templates listed above that I maintain in this thread.

You are right I just checked the directories it appears to be SAMBA. -rw-r--r-- 1 root root 2.7M Oct 6 15:08 log.rpcd_classic -rw-r--r-- 1 root root 2.7M Oct 6 15:08 log.rpcd_epmapper -rw-r--r-- 1 root root 2.7M Oct 6 15:08 log.rpcd_fsrvp -rw-r--r-- 1 root root 12M Oct 6 15:08 log.rpcd_lsad -rw-r--r-- 1 root root 2.8M Oct 6 15:08 log.rpcd_mdssvc -rw-r--r-- 1 root root 2.7M Oct 6 15:08 log.rpcd_spoolss -rw-r--r-- 1 root root 2.7M Oct 6 15:08 log.rpcd_winreg -rw-r--r-- 1 root root 176K Oct 6 15:08 log.samba-dcerpcd -rw-r--r-- 1 root root 4.9M Oct 6 08:45 log.samba-dcerpcd.old -rw-r--r-- 1 root root 165K Oct 6 14:57 log.smbd -rw-r--r-- 1 root root 4.9M Oct 6 03:16 log.smbd.old -rw-r--r-- 1 root root 1.3K Sep 28 15:25 log.wb-SCARIF -rw-r--r-- 1 root root 4.7M Oct 6 15:09 log.winbindd -rw-r--r-- 1 root root 426 Sep 28 15:25 log.winbindd-idmap -rw-r--r-- 1 root root 4.9M Oct 2 17:50 log.winbindd.old I have had some issues with my MAC (networking issues) so it's likely my mac is causing issues with SAMBA especially time machine backups

/var/log doesn't seem to have anything too large, unraid is reporting 52MiB in logs -rw-r--r-- 1 root root 85 Oct 6 00:00 apcupsd.events -rw-r--r-- 1 root root 193 Oct 6 00:00 apcupsd.events.1 -rw-r--r-- 1 root root 193 Sep 29 00:00 apcupsd.events.2 -rw------- 1 root root 0 Aug 22 03:17 btmp -rw-r--r-- 1 root root 0 Apr 28 2021 cron -rw-r--r-- 1 root root 0 Apr 28 2021 debug -rw-r--r-- 1 root root 71K Sep 28 15:23 dmesg -rw-r--r-- 1 root root 41K Oct 6 06:07 docker.log -rw-r--r-- 1 root root 0 Feb 13 2021 faillog -rw-r--r-- 1 root root 12 Oct 6 09:25 gitcount -rw-r--r-- 1 root root 20K Oct 6 09:25 gitflash -rw-r--r-- 1 root root 292 Oct 6 14:36 lastlog drwxr-xr-x 4 root root 140 Sep 28 15:25 libvirt/ -rw-r--r-- 1 root root 0 Apr 28 2021 maillog -rw-r--r-- 1 root root 0 Sep 28 15:23 mcelog -rw-r--r-- 1 root root 0 Apr 28 2021 messages drwxr-xr-x 2 root root 40 Aug 10 2022 nfsd/ drwxr-x--- 2 nobody root 60 Sep 28 15:24 nginx/ lrwxrwxrwx 1 root root 24 Aug 22 03:15 packages -> ../lib/pkgtools/packages/ drwxr-xr-x 5 root root 100 Sep 28 15:24 pkgtools/ drwxr-xr-x 2 root root 740 Oct 4 04:00 plugins/ drwxr-xr-x 2 root root 60 Sep 28 15:24 preclear/ drwxr-xr-x 2 root root 40 Oct 4 14:37 pwfail/ lrwxrwxrwx 1 root root 25 Aug 22 03:17 removed_packages -> pkgtools/removed_packages/ lrwxrwxrwx 1 root root 24 Aug 22 03:17 removed_scripts -> pkgtools/removed_scripts/ lrwxrwxrwx 1 root root 34 Sep 28 15:24 removed_uninstall_scripts -> pkgtools/removed_uninstall_scripts/ drwxr-xr-x 3 root root 360 Oct 6 08:45 samba/ lrwxrwxrwx 1 root root 23 Aug 22 03:15 scripts -> ../lib/pkgtools/scripts/ -rw-r--r-- 1 root root 0 Apr 28 2021 secure lrwxrwxrwx 1 root root 21 Aug 22 03:15 setup -> ../lib/pkgtools/setup/ -rw-r--r-- 1 root root 0 Apr 28 2021 spooler drwxr-xr-x 3 root root 60 Sep 27 2022 swtpm/ -rw-r--r-- 1 root root 387K Oct 6 14:36 syslog -rw-r--r-- 1 root root 69K Oct 6 14:38 tailscale-utils.log -rw-r--r-- 1 root root 4.0K Oct 5 23:59 tailscale-utils.log.1.gz -rw-r--r-- 1 root root 4.1K Oct 4 23:59 tailscale-utils.log.2.gz -rw-r--r-- 1 root root 4.9K Oct 3 23:59 tailscale-utils.log.3.gz -rw-r--r-- 1 root root 4.0K Oct 2 23:59 tailscale-utils.log.4.gz -rw-r--r-- 1 root root 12K Oct 6 14:33 tailscale.log -rw-r--r-- 1 root root 2.7K Oct 5 23:57 tailscale.log.1.gz -rw-r--r-- 1 root root 2.3K Oct 4 21:22 tailscale.log.2.gz -rw-r--r-- 1 root root 4.3K Oct 3 21:17 tailscale.log.3.gz -rw-r--r-- 1 root root 8.3K Oct 2 23:51 tailscale.log.4.gz drw-r--r-- 2 root root 60 Sep 28 15:24 unraid-api/ -rw-r--r-- 1 root root 1.2K Sep 28 15:23 vfio-pci -rw-r--r-- 1 root root 0 Sep 28 15:23 vfio-pci-errors -rw-r--r-- 1 root root 708 Sep 28 15:23 wg-quick.log -rw-rw-r-- 1 root utmp 7.9K Oct 6 14:36 wtmp My isos are in one of my two cache drives, but does that make a difference I'm not using them very often

I'm seeing a lot of logs for spinning up and down drives, is there a way to disable this? I'm also dealing with high log usage in general with 43% log usage in 7 days. Any assistance is greatly appreciated diagnostics.zip

Apologies, that was my mistake diagnostics attacheddiagnostics-20240903-1638.zip

I'm having an issue where the Nvidia Driver isn't detecting/reporting GPUs. I had a 1050ti in my first PCiE slot and everything was working no problems. I recently moved the 1050ti to the 3rd slot and added a 3060 to the 1st slot. This is a configuration I had in the server a few months ago. But now the driver isn't finding the GPUs even though Unraid is and can use them in VMs. I tried deleting the plugin and driver and reinstalling but no luck, any help would be greatly appreciated.

This ended up fixing the issue I quadrupled the size of the arc and it is no longer having this issue. Hopefully once they release future updates allowing it to be dynamic there can be an easier solution.

I was looking at the logs is it possible unraid is spinning down disks and arc_evict then has no where to write to? Because the logs appear to stop outputting right after it lists drives it's spinning down then no longs until I ssh in. My current set up is 2 SSD cache pools, 1 is in a raid setup (i forget which number) but it is 3 drives all ZFS, then the second is raid 0 with ZFS (snapshotting it to HDD ZFS pools), and each drive in my system is ZFS formatted to be the hybrid ZFS system.

What exactly is arc_evict and what would cause it to run, and what would lead to it running at 100% for hours on end. These days my server isn't crashing but it's spending more time maxed out on running arc_evict then anything else. I'm currently away so currently i'm not in a position that make it easy to copy logs but when I return to the server I can, and is it ok to post the logs here or do I need to check anything to anonymise it.

That would make sense the diagnostics I got after rebooting so I'm realizing now they may not be relevant to solving this arc_evict issue

Yeah plex was streaming and recording live TV. I was unable to interact with the dashboard and didn't try turning it off but i'm fairly certain it was caused by the arc_evict process that stopped all containers and other processes. I attached the ouput of the top command from when I used ssh into the system.

I have had this issue a few times where everything on my server stops working and the top menu shows the command `arc_evict` at 100% on the CPU. At the same time of this happening everything else appears to shutdown or at least cease to respond including the dashboard, all my docker containers, VMs, SAMBA, etc. The only thing that appears to work is ssh but sometimes that freezes up too. In the past i've been able to shutdown via ssh access or in the past had to restart physically after hours of unresponsiveness from the server. For context all my drives do use ZFS cache pools together and individual hard drives are individual ZFS pools. I attached the diagnostics from my server after reboot. scarif-diagnostics-20240403-2127.zip

The solution, at least as of the last two weeks was just to upgrade to the updated version on unraid, I had held off due to high use on my server but once I updated things haven't been crashing. Still not really sure how this all started, but it is resolved now.

I appreciate the quick response, I did realize the syslog server was writing to a share so it's possible that went down when things froze up I updated it to store a copy on flash if it happens again i'll try to figure out what happened and I will try the safe mode, is there any other tools to check hardware for these potential issues?

This has happened two days in a row. I'm unsure the reason but things will freeze up. Yesterday this happened while I was working with a minecraft server in a docker container today it happened while working in a VM on some more demanding processes. I had something similar a few weeks back I think top showed something related to a process with `arc` in the name. I attached system diagnostics and the logs from my syslog. scarif-diagnostics-20240226-2306.zip syslog-192.168.1.64.log