[Samba] smbd cannot be killed

[Ted Hilts]

Volker Lendecke wrote:
> On Thu, Mar 19, 2009 at 04:58:13PM -0600, Sergey Manucharian wrote:
>   
>> I run a server with Archlinux and Samba 3.2.5 as PDC for ~30
>> Windows workstations. I have a share containing a CRM-like system with
>> whole bunch of DB files and Windows executables (GoldMine). People run
>> the executables remotely from that share, and regularly it works
>> properly. But once in a week it stops working - the DB program cannot
>> access some files in the share, and also I cannot restart the Samba -
>> several instances of smbd continue running and even "kill -9 smbd"
>> doesn't help. After I restart the system in such cases everything
>> starts working properly.
>>     
>
> If kill -9 does not help, you have a kernel problem. There
> have been kernels with broken inotify that leads to runaway
> smbd processes chewing CPU. You might want to try
>
> notify:inotify = false
>
> or upgrade your kernel.
>
> Volker
>   
I don't think so.  I think his cpu is swamped  -- I've seen this many 
times.  I solved the problem by having a monitor machine which I telnet 
(but you can log on to another machine in several ways). When the 
problem occurs the pre connect between both machines allows the monitor 
machine tto execute a command line  "kill 2345" or whatever the process 
id happens to be. It is desireable to have the monitor machine window or 
desktop determine the process ID in advance so that the kill command is 
sitting there waiting for the enter key to be pressed.  This makes the 
process very fast otherwise it may take 5 minutes to obtain the 
information from the swamped machine over to the monitor machine.  I do 
not know of any way of "limiting" the CPU useage so that when the 
swamping occurs there is enough available cpu that one can do 
administrative tasks.  But when the monitor approach is used there 
always seems to be just enough CPU resources in the swamped machine to 
allow continued communications (slow) with the monitor machine. I do 
this monitor thing as user "name" and not as "sudo".  Hope this helps.  
Anyway, in a big system there should probably always be a monitoring system.

Good luck, thanks Ted.