spawning smb processes out of control

eirvine eirvine at tpgi.com.au
Fri Dec 7 13:32:06 GMT 2001


Hi,

Yes, I've seen this on Solaris too. We also noticed *some* smbd processes using huge amounts of memory and
cpu time.

Using truss, we found that those processes were stuck
in an endless loop dealing with a recursive symlink.

I now have "follow symlinks = no" as a default in my
smb.conf and I haven't seen either problem since. 

I also removed the reursive symlink :)

Eddie.

Hans-Peter Bernhard wrote:
> 
> I had nearly the same problem, on a linux system maybe it is not
> a great help but I upgraded my linux system from suse 7.2 to suse 7.3
> and I never saw this behaviour again.
> I assume, as I patched the lpd (the week before) I had to install
> newer clibs maybe something went wrong.....
> It is not a nice solution, but I am serving about 200 workstations and
> 800 users and I never saw it again.
> 
> hpb
> 
> Alfredo Ramos schrieb:
> >
> > Please help. I have a weird problem with samba 2.2.1a.
> >
> > For the most part, Samba behaves just wonderfully. I'd say, 99.9% of the
> > time it chugs along serving applications, sharing files and printers like
> > a champ. But at least once a week, and some weeks, three or four times,
> > the samba server starts spawning smbd processes like there's no tomorrow
> > until it runs out of resources. At that point, users services come to a
> > complete halt. Nobody is able to login, print, or do anything else. The
> > load on the server becomes extremely high, and the only way to recover is
> > by killing all the smbd processes that were spawned by the server. The
> > number of processes spawned goes way past the 500 mark. If you're lucky
> > and the server responds, you can kill the processes and everything goes
> > back to normal. If the server is beyond recovery, only a reboot will get
> > the server back.
> >
> > The server is a dedicated Sun Enterprise 220R with truckloads of memory,
> > running Solaris 8. The weird part is that, the out-of-control spawning can
> > happen when there's only a handful (8 or 10) of users, or when the labs
> > are packed, sometimes during the day, at other times at wee hours of the
> > night.
> >
> > The logs don't show information that I could relate the this problem. I've
> > set the debug level to 3 or 4, and the only thing that I was able to spot
> > was a problem with the oplocks. Something to the effect that the server
> > was waiting for an oplock to be released, and then receiving a
> > notification without expecting it, also about oplocks, (sorry, I do not
> > have the log output anymore. I think I can get it again though).
> >
> > Anyway; thinking that this was the cause of the problem, I disabled the
> > oplocks parameter on the smb.conf file, but it did not make a difference.
> >
> > If anybody has experienced the same problem, or knows what is causing it,
> > I would really, I mean REALLY, appreciate pointing me in the right
> > direction to correct it.
> >
> > Thanks;
> >
> > Al Ramos.
> >
> > ---------------------------------------------------------------------------------
> >                                            | Alfredo Ramos
> > This space available for rent.             | Educational Technology
> > Get your product moving. Advertise here!   | Rice University.
> >                                            | Email: ralf at is.rice.edu
> > ---------------------------------------------------------------------------------




More information about the samba-ntdom mailing list