miicar

cuz i look at my log all the time, and that's stupid that it has diag turned on by default....if anything else worked for dum-Dells fan controller i would use that....MY QUESTION STILL STANDS

How do i stop this plugin from pointlessly logging every time it changes fan speed. it floods the system log with pointless information...it should have either a tiered log setting, or log on/off, like every other program does! Flooding my logs with "temperature moved a bit...changing the fan speed 20%" is pointless, as its working as expected. (and no, i shouldn't have to have 4 different log filter plugins running alongside this one, to silence pointless information)

i think that means you have 7 different fan headers to chose from!

no this is several times an hour...the gui sometimes says "uptime 10 mins"...it seems like a soft crash too. The logs from unraid show: "Aug 27 19:24:35 (my server name) kernel: docker0: port 6(veth61056a3) entered disabled state Aug 27 19:24:35 (my server name) kernel: vethba5c05c: renamed from eth0 Aug 27 19:24:35 (my server name) kernel: docker0: port 6(veth61056a3) entered disabled state Aug 27 19:24:35 (my server name) kernel: device veth61056a3 left promiscuous mode Aug 27 19:24:35 (my server name) kernel: docker0: port 6(veth61056a3) entered disabled state Aug 27 19:24:38 (my server name) kernel: docker0: port 6(veth3f3da73) entered blocking state Aug 27 19:24:38 (my server name) kernel: docker0: port 6(veth3f3da73) entered disabled state Aug 27 19:24:38 (my server name) kernel: device veth3f3da73 entered promiscuous mode Aug 27 19:24:39 (my server name) kernel: eth0: renamed from veth4ade7af Aug 27 19:24:39 (my server name) kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth3f3da73: link becomes ready Aug 27 19:24:39 (my server name) kernel: docker0: port 6(veth3f3da73) entered blocking state Aug 27 19:24:39 (my server name) kernel: docker0: port 6(veth3f3da73) entered forwarding state" Its hard to capture the storj logs unless i sit here and watch the unraid logs to see it happen in real time and quickly copy the storj logs...normal operation, otherwise, quickly fills the logs with normal download/upload processes...although my score in the gui is defiantly suffering! what was that corrupt file? As i said, i re-installed the node and its still doing this. I was thinking its cuz my slow array takes to long to feed it info (had DB corruption issues when the DB was on the same array as the data; but i have moved them to another pool of NVME drives, and things have been great ever since). what else, other then data, gets read? maybe i should move everything but the data off that slow array. weird that this started happening AFTER i removed the slowest disk from the mix (and that disk is now in another PC with a windows based node...running fine). Probably unrelated, but i don't get why i have random IP6 Stuff in my logs, when i have all IP6 stuff disabled on both my server and the router and switch...i've just ignored it, cuz it doesn't seem to do anything bad...just annoying to look at.

me too. i just noticed it happening. rebuilt docker image and installed everything again...still doing it every few mins sometimes! quite scary as this is a 2 year old node and my suspension/online score is dropping fast! No one seems to have answers to it tho...

one of my servers has been doing a disk replace on a pool for a couple weeks now...its still moving extents etc in the log, so im assuming its doing what its meant to. i guess its moving them at 5 1/4" floppy speeds? Not sure why its taking this this long (i added a 4TB drive to replace a 350GB). "btrfs fi show" tells me its moved about 48GB in the last 36 hours...i miss dial up, i think it was faster. i need to reboot my sever, but im scared to lose the pool if i do...

just wanna laugh and say i opened up terminal to use this force stop method, and i guess my server got scared and suddenly let the docker stop, without typing a dam thing ...this experience continues to feed my theory that computers are just demons in physical form!

to add to this; if this is really the cause...maybe unraid needs to have a way to disconnect from "any remote console", as i don't have any open and it still storms and brings my network access to the server to a standstill about 4 times a day...even after a reboot. so if its seeing a ghost open, give me a way to disconnect from it!!

It seems like no one has any answers to this, but my staff are having to work locally cuz they "cant trust the network"...and i don't blame them. i blame me, need some experts to chime in here and help! i have a dozen computers on a pretty basic network. 2 or 3 of these PC's are the ones showing up in the log-storm, ive run the usual deep scans, SFC's etc. one PC is a fairly new install. so what's bombarding the server and bringing it down? Once an expert chimes in here, i'll send them my logs.

I have a bunch of old and slow HDD's in a pool that supply my STORj node with space. Its my way of keeping the landfills less crowded! This has been working fine for a couple of years now. I have been having stability issues with my server, so im paying attention to the logs allot now. I have noticed the storj docker seems to keep resetting itself (but not fully...just the networking side?)! No other containers do this. They are all set up as "bridge mode" to a x4 br0 802.3ad (4) mode (and yes, i have set up LAG on the managed switch...its all working as far as i can tell). The dockers log seems normal, with the occasional yellow "upload/download failed" warning that we have learned to ignore as it just means my node lost the file race. Why is this happening? anyone have any light to shed? Additionally, is there any way to tell which docker corresponds to the "docker0: portX" in the system logs? It seems to be unrelated to anything in the docker tab. Thanks for ya'lls help

So i have been battling an unruly docker container...in that process i have become quite frustrated on the lack of continuity between the "docker tab" and the system log. The LOG shows which docker is resetting itself with "docker0: portX (where "X" could be any number it decides to assign to that docker, depending when it was created and started); so i go over to the docker tab to see which "portX" docker is being dum...and there is no way to cross reference this. Sure, im sure i could pour through linux forums and find that one line of code that tells me what docker container "portX" is, but really, should it be this confusing; and so far, i haven't found that decryption code? Currently, the only way i can figure out what "...portX" is, is by restarting each docker, looking at the log and seeing what port it was assigned this time around (yes, it changes, at a whim, depending on other factors). Well that works, it's also extremely primitive, time consuming, insulting and stupid! If the log is going to output information in one format, the docker tab MUST have that same format somewhere as well to cross reference (if it is, its well hidden and i apologize for my apparent blindness). Hopefully this can be easily addressed and either the log outputs the name of the docker itself, or the docker GUI has the "portX" info that it was assigned! again, if the translation, from port number to real container name, is there, in my face, and i'm missing something, please tell me and i will learn (and I'm sure many searching this forum can as well)...otherwise, not sure how this was overlooked...seems elementary

ever figure this out? i have a docker container doing the same thing...well at least i think its only one

We still aren't sure what causes a docker to do this? im assuming we think its a docker?? (I don't have NZBget)

I am having similar issues in my unraid logs. When this happens, it grinds all server access speed, to a to almost useless as well. i don't want to "HIDE" the problem, i want to understand, and fix, why (ONLY) one PC connected to my network is giving me this error, and why its pissing off my employees and making me look like a fool! Yes, i know i am way over my head, but this is where i learn best!

as the update to 6.12.3 seemed to have stopped this issue...i would say its a related issue

So i don't have the docker hang issue (although its randomly come up in the past BEFORE i upgraded to 6.12.2), my "bzfirmware" and "bzmodules" are the ones hanging themselves! and unmount script listed (and my old one) doesn't work for these loops....i could unclean shutdown...but that's dum too! Ahh shucks, i was hoping to update my production server to 6.12.x to solve some weird SMB/NGIX bug that randomly chokes transfer speeds...

imagine if they made a setting to quiet the pointless logs, like most other programmers do...

Just going to chime in here, i would also rather have a hard limit, not a percentage. I have situations where a cache pool is larger then some of my array disks, so with the current system (if i understand it correctly), i can't utilize my cache to its full maximum, cuz its calculating the 100GB % off the smallest drive in my array ...being able to use "100GB" would just make more sense (being able to have min free on both array and cache pools as separate options would be amazing, but beggars can't be choosers)! And yes, the new notifications "bell" is awful! 😝

I have a dell "0NK70N" mobo. Using Autofan floods my system logs with pointless info like "...autofan: Highest disk temp is 32C, adjusting fan speed from: 128 (50% @ 888rpm) to: 196 (76% @ 4967rpm)" every few mins (or every few seconds if the server is putting in work). The movie quote, "frankly my dear, i don't give a dam" comes to mind. Its useless (my dashboard tells me fan speeds, if im curious), and bury's important information that i might want to see in the logs, from earlier in the day. HOW DO I SHUT THIS UP??? I don't need to know what the plugin is doing every time it changes fan speeds! I not sure why it even does this by default! Please tell me someone has a way to fix this?!?!?! --- A separate question: Autofan only sees 3 out of the 8 fans/headers (incl CPU fans). Additionally, one of the 3 fans that it does see, it doesn't seem to be able to control at all! For now, ive resorted to using a powered fan splitter and jerry rigged jumpers (yay dell non-standard fan headers...companies should be sued for this kinda nonsense; but i digress) to one of the headers that is controlled by autofan, and force most of the fans to run on that sensor bank...but its not ideal. --- Lastly: is there a way to make Autofan control fans based on CPU/MOBO/Video/etc temps, instead of just HDD's? This might not be possible without a full re-work, but thought i would ask! +++ Normally my Google-fu hits hard, but i can't seem to knock this one out! So I gave up, and am asking ya'll!

Well for me, it totally tanks the performance of SMB for other users. we have about 8 PCs accessing the server during a given day, and when this random message appears, everything doesn't work as it should. files are slow to download/upload etc. It does seem that the 6.12.x version addresses this, and i hope it is resolved...im sick of getting yelled at.

LMAO So, what if you are already on Q35 and this AMD/HDMI Audio is still a plague (worse then the old VM on i440fx)????? It used to be random...now its every time i shut down the VM, i have to re-install the driver. I'll re-install the driver (again) while i wait for anyone to chime in...

I am also RANDOMLY getting this error in the logs, and while that PC (attached to the IP) isn't even being used. sometimes other random PCs (IP) on the network are showing up as this error as well. it is quite frustrating, as my designers cannot access their files, or the access is extremely slow for a while...then its fine for weeks.... It seems 6.11.5 has some weird bugs the older versions didn't...is unraid trying to do too much? Does anyone have real world experience with this (nginx error) issue existing on earlier versions of 6.11.x? I am using multiple pools, and i am afraid of going back too far in versions (till 6.12.x is official/stable as the changelog seems to address this nginx issue) will start causing me other issues as well. I can cleanly go back to 6.11.3 (UNraids built in downgrade), but if i'm still getting the SMB locking up issues, whats the point. It seems that 6.10.x didn't have this issue, so if i have to, i'll go back to that i guess.

I too am missing the NDI stuff in the latest container! This is a new instal. I used it before, and everything worked great (i just had a useless PC to stream from before now).

Also having these random errors show up in my unraid logs (referencing a couple of workstations on the network); and my staff is complaining of slow/timeout access to some shares...but when i try to access the same files (from other PC's on the network), there is no issues and it uses the network speed available to it! I need to get to the bottom of this as my staff are finding "creative" ways of getting around this (instead of telling me), that is causing chaos and files to be put in random places.

Same here...not using firefox...