Kaldek
-
Posts
101 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by Kaldek
-
-
The root cause here appears to be entries in the file /boot/logs/syslog-previous related to the previous execution of the Mover when Mover Logging is enabled.
The diagnostics script sees these, and runs the "sed -i" command for every entry found in the syslog-previous file. Deleting the syslog-previous file stops this issue from occurring, as would not having Mover Logging enabled I suspect.
I do not recall a warning for Mover logging about it impacting Diagnostics. I know it mentions potentially filling up log files, but not an impact to the diagnostics script. -
Changed Priority to Minor
-
OK, I had to delete the file /boot/logs/syslog-previous to remove the constant banging on about these non-existent files.
-
Post reboot and the GUI diagnostics is still waffling on about these files that just don't exist on the cache drive.
-
Array stop and reboot is working at this point, after performing the mover. Will run diagnostics interactively after reboot to see if the mover has all the weird sed commands on non-existent files still.
-
WebGUI just died with this message:
-
I have no idea what all this "syslog-previous" stuff is for.
-
I just moved all files off the cache:
However when I run the Diagnostics command in the WebGUI agian it is still referring to these files??
-
I am unable to refresh the browser tab with the Diagnostics page, nor even change the URL to, say, the Dashboard. The tab has to be closed and a new unraid tab opened to access the Web GUI again.
-
However a completed file named "unraid-diagnostics-20240408-1001.zip" now exists in /boot/log.
-
The GUI execution has now hung here. There is no file attempting to download.
-
The command being run is "sed -i" as per the attached image:
-
Changed Status to Closed
-
Confirmed at my end that not using Active/Backup NIC Failover has kept my system stable for 25 days.
-
14 hours ago, itimpi said:
If you use the “Mirror to Flash” option then there is no direct dependency on the network working so more chance of catching something.
Fair enough. Not sure if I'm game to turn active/backup back on and wait for a crash again. I had so many crashes I think I'm still in the "just want stability for a while" phase.
I guess if that means this bug report has to be closed due to that, I'll just have to live with it. -
1 hour ago, ChatNoir said:
You should set up a syslog server and post the log file after the issue happened.
Yeah I did plan on that but given the fact that I wasn't even getting Kernel Panic messages on the console, and the fact that it's core network driver related, the chances of that syslog message even getting out were...low.
-
6 hours ago, nblom said:
I just had it happen again here too. I am back on v6.12-RC5 when it happened. My '/run' had filled up all 32MB.
Turns out my plex container had filled up the logs with a bunch of stuff related to the Nvidia Drivers. I have now set the extra parameter of '--no-healthcheck' and that seems to have slowed the increase of the logs down.
Concurred; mine had also just filled up with the same consumption caused by the log.json file used by Plex.
-
Well, DNS kept going after having IPv6 disabled but Docker had a fit and lost its mind. Server reboot required.
I'll just reboot it every couple of days until RC7 is out.
-
1 hour ago, nblom said:
Reverted to RC5 to see if that fixes it. Thanks.
It's been 7 days for me with no issues, and the only change I made was to disable IPv6.
User JorgeB above mentioned there is an RC7 floating about that fixes a Docker Bug which could cause the issue. He must be a member of the team as he's a moderator. -
8 hours ago, Squid said:
A lot of routers are terrible at handling DNS requests. But yes to make the change, docker has to be stopped.
I can say with some confidence this is not a DNS server issue for me.
- Nothing changed except unRAID version
- unRAID was always set to use the router, followed by Google for DNS
- /etc/resolv.conf shows as blank when the problem occurs
-
7 hours ago, nblom said:
I just attempted to stop docker and it failed. I then went to change Network Settings and the UI still thinks docker is running.
Got this in the logs:
May 25 10:41:55 Fenrir avahi-daemon[29851]: Service "Fenrir" (/services/sftp-ssh.service) successfully established. May 25 10:41:56 Fenrir root: waiting for docker to die ... May 25 10:41:57 Fenrir root: waiting for docker to die ... May 25 10:41:58 Fenrir root: waiting for docker to die ... May 25 10:41:59 Fenrir root: waiting for docker to die ... May 25 10:42:00 Fenrir root: waiting for docker to die ... May 25 10:42:01 Fenrir root: waiting for docker to die ... May 25 10:42:02 Fenrir root: waiting for docker to die ... May 25 10:42:03 Fenrir root: waiting for docker to die ... May 25 10:42:04 Fenrir root: waiting for docker to die ... May 25 10:42:05 Fenrir root: waiting for docker to die ... May 25 10:42:06 Fenrir root: waiting for docker to die ... May 25 10:42:07 Fenrir root: waiting for docker to die ... May 25 10:42:08 Fenrir root: waiting for docker to die ... May 25 10:42:09 Fenrir root: waiting for docker to die ... May 25 10:42:10 Fenrir root: docker will not die! May 25 10:42:10 Fenrir emhttpd: shcmd (419): exit status: 1 May 25 10:42:10 Fenrir emhttpd: shcmd (420): umount /var/lib/docker May 25 10:42:16 Fenrir nmbd[29797]: [2023/05/25 10:42:16.966525, 0] ../../source3/nmbd/nmbd_become_lmb.c:398(become_local_master_stage2) May 25 10:42:16 Fenrir nmbd[29797]: ***** May 25 10:42:16 Fenrir nmbd[29797]: May 25 10:42:16 Fenrir nmbd[29797]: Samba name server FENRIR is now a local master browser for workgroup WORKGROUP on subnet 172.28.0.15 May 25 10:42:16 Fenrir nmbd[29797]: May 25 10:42:16 Fenrir nmbd[29797]: *****
I can confirm the same behaviour. I also tried to stop the array so I could change DNS settings and see if it forced DNS to come back, but it constantly said that Docker was still running.
I'm not sure if I said this in my original post either, but it was also impossible to stop the array because Docker would never stop, and as a result it could not unmount the cache pool. -
3 minutes ago, guill_019 said:
This solution works for me!!!!!!!!
Thanks a lot ich777
Can I do something to make this a permanent fix or I need to wait for an OS update? (not a big deal as I rarely need to reboot my server)
If @ich777 is responsible for this part of unRAID I'd say they'll be working on a fix ASAP. They already provided a permanent fix for Nvidia drivers.
-
10 hours ago, guill_019 said:
When you say "load the Intel module for your onboard graphics card" how do you do that exactly?
That's what the "modprobe i915" does - it loads the module. -
12 hours ago, ich777 said:
@Kaldek & @sterofuse & @almulder
Fixed!
Update the Nvidia-Driver Plugin (make sure that you are on version 2021.03.10) and reboot your server into GUI mode again.
@ich777 I can confirm this update fixes the issue for me.
For anyone who's rebooting their server remotely, you can tell if the permanent fix (the update to the nvidia plugin) worked just by running "nvidia-smi" at a terminal prompt.If it's working you will see Xorg running as a process on the GPU:
-
1
-
Diagnostics never finishes due to huge # of files
in Stable Releases
Posted
I get that - it's more that this should be a call-out about impact to reboots. Like, I was utterly confused by this as there was no warning *what* was delaying the reboot. Lots of unRAID users out there less technical than me.