No need to stop sharing SMB, just stop using WSDD. It's an option in the UI.

Yea, I just disabled WSDD. 

On 5/12/2020 at 6:07 PM, BRiT said:

No need to stop sharing SMB, just stop using WSDD. It's an option in the UI.

Thank you. Is there any fix for this yet?

Edited June 27, 20206 yr by itskamel

46 minutes ago, itskamel said:

Thank you. Is there any fix for this yet?

Not yet, still have it disabled. I'm waiting for the new version, 6.9, to try again and check.

I'm seeing this now on a brand new (to unraid) system running 6.8.3.   It's a trial key with only 2 drives and no additional setup--no vm's, no docker setup, not even any plugins installed or any data loaded/shares.

 

So likely this is more basic than suggested above.   Note, I don't have this issue on my primary production system, so maybe it's cpu generation based or some other hardware interaction.

 

FWIW, old system is 2x AMD 2431 on a Supermicro H8dm8-2,   new system is 1x AMD 6274 and Supermicro H8DG6.

 

 

I now get this happening regularly on a Lenovo Thinkstation E31 (Xeon E3-1225v2), never happened in 8 years continuous running on my old HP Microserver N36L.  Have been running unraid 24x7 since 2011 (originally version 4.7, currently 6.8.3 on a Basic license) and never had the problem until moving to the new hardware about 4 months ago.  Same installation - I just moved the USB drive and all the disks across to the Thinkstation and the problem started and has been recurring since then.  Stopping then restarting the array fixes it for a few days or weeks, then it comes back again. 

6 minutes ago, tj80 said:

I now get this happening regularly on a Lenovo Thinkstation E31

WS Discovery (the wsdd process) did not even exist until version 6.8 of unRAID so you could not have had this problem until moving to that version of the OS, regardless of hardware configuration.

 

There is nothing so far that indicates the problem is hardware related so I don't think your move to the Thinkstation was the trigger for the problem. 

 

If you are not using WS Discovery, you can always disable it in SMB settings and the problem is guaranteed to disappear.

 

 

WS discovery is a welcome convenience on my network and I would prefer to leave it running, is it possible to maybe lock it to a specific core to play more nicely with Docker and VM CPU Pinning settings?

 

As it stands, I use CPU pinning to give VM's and Docker Containers access to certain cores to help with higher CPU dependent things like a game server or Plex container, so it would be nice to just throw WS Discovery on specific cores that aren't shared with the CPU dependent stuff.

3 minutes ago, axipher said:

WS discovery is a welcome convenience on my network and I would prefer to leave it running, is it possible to maybe lock it to a specific core to play more nicely with Docker and VM CPU Pinning settings?

 

As it stands, I use CPU pinning to give VM's and Docker Containers access to certain cores to help with higher CPU dependent things like a game server or Plex container, so it would be nice to just throw WS Discovery on specific cores that aren't shared with the CPU dependent stuff.

There isn't a way to specify a core for this function. Additionally, when the issue happens, the core that is at 100% may hoop to another core.

Same problem, 6.9 beta 25.  

 

Shutting down Docker made it stop.  I only have one container in there and it wasn't even started.

On 8/15/2020 at 9:00 PM, trevisthomas said:

Same problem, 6.9 beta 25.  

 

Shutting down Docker made it stop.  I only have one container in there and it wasn't even started.

Same here. Shutting down docker (in the settings page->docker) fixed it here, too. Strange because all containers were stopped already, so it must be something with the docker service itself.

Edited September 18, 20205 yr by Videodr0me

Today after 2 month uptime I noticed 1 core is at 100%, ... wsdd
I don't know which version is used in Unraid but I found an old issue which was fixed:
https://github.com/christgau/wsdd/pull/42

 

Patch details:

 

Quote

This prevents infinite loops on zero-length routing attributes.

 

Edited September 30, 20205 yr by BRiT

I hope this gets fixed on UNRAID 6.9. My WSDD still disabled. 

I just had this problem for the first time. 

 

Changed a random smb setting and it's gone. 

 

Hope it will be fixed in unraid 6.8.4.

52 minutes ago, Fallwater said:

fixed in unraid 6.8.4.

Won't be 6.8.4

 

6.9 will be next 

Had this today with 6.8.3

 

I restarted Samba through the Webterminal as follows, which restarts WSDD as well:

samba restart

 

Does anyone have mounted SMB Shares (I have)? 

same here on 6.9.0 rc2. For no apparent reason. 1 VM win 10 was running at the time. Stop-star of array fixed it, which is logical as SMB get's also stopped...

This is happening to me too on v6.8.3

 

i followed the guy above who got the process id from top, killed it and typed wsdd to restart. The process had been running for a while. It seems to have cleared the issue for now but I guess the only perm fix is to disable WSD in the samba settings (need to stop the array to change it)

I've just had this issue too now.

Have all of you with this issue tried the WSD Options setting mentioned in the bug report thread for this problem?

 

Adding -i br0 to the WSD Options has largely eliminated this problem for me. It is not completely gone but I only see it every 3-4 months or so now.  It's not a fix as it still can occur, but for many it at least greatly lessens the frequency with which the 100% CPU problem occurs.  YMMV.

 

Disabling WSDD prevents the problem 100% of the time...

18 hours ago, BRiT said:

Disabling WSDD prevents the problem 100% of the time...

Yes, it does, but, I prefer it over NetBIOS/SMB v1.0 so I disable those instead on unRAID and all Windows clients and run WSDD. 

 

Overall (even with the occasional 100% CPU issue) it has been more reliable in my network than trying to keep SMB v1.0 running despite Microsoft's best attempts to kill it.

Edited February 20, 20215 yr by Hoopster

My "solution" is this script (executed every 5 minutes):

 

#!/bin/bash
# #####################################
# Script:      WSDD Restarter
# Description: Restarts WSDD if its CPU usage is too high
# Author:      Marc Gutt
# 
# Changelog:
# 0.1
# - first release
# 
# ######### Settings ##################
wsdd_cpu_limit=5.0
# #####################################
# 
# ######### Script ####################
# make script race condition safe
if [[ -d "/tmp/${0///}" ]] || ! mkdir "/tmp/${0///}"; then exit 1; fi; trap 'rmdir "/tmp/${0///}"' EXIT;
# get pid and cpu usage
wsdd_pid=$(pidof wsdd)
if [ $? -eq 0 ]; then
    # check cpu usage
    wsdd_cpu_usage=$(ps -p ${wsdd_pid} -o %cpu --noheader | xargs)
    if [ $? -eq 0 ]; then
        if $(awk 'BEGIN {exit !('$wsdd_cpu_usage' >= '$wsdd_cpu_limit')}'); then # https://stackoverflow.com/a/45591665/318765
            samba restart
            /usr/local/emhttp/webGui/scripts/notify -i alert -s "WSDD restarted!" -d "CPU usage was too high!"
        fi
    fi
fi

 

On 6.9, still happening, issue not fixed. I am using the "-i br0" option, but the process still bugs out after some time.