Thanks for the input James. I've actually tried some of the stuff that you mentioned. When I experience the problem, the CPU isn't being taxed in any way. Also, the mount point for the share is not removed and cannot be removed because the system thinks that the directory is already mounted (busy). Restarting Samba doesn't change this status at all. As I said earlier, it most likely is not a Samba problem. It seemed to be more of a problem in the kernel, as that is where I expect filesystem mounting is tracked, etc.
Rob James Sparenberg wrote: >this is neither a fix or a reason. But it might enable you to >"fix" the situation without a reboot. It sounds like what >happened was that samba was desperately trying to access a >non-existent share and took up all of your CPU cycles, thereby >fuzzing up your DHCPD. What I would do is. > >1. touch or otherwise recreate the share/directory that was >removed so that samba can find something. > >2. Umount the share > >3. remove it from being automounted if that is being done. > >4. restart Samba > >5. Make sure it didn't try and remount it again. > >6. Remove the share/directory from the other box. > >This isn't a fix but a work around for keeping your system >running. Then I'd go to the Samba site and report this as a bug >with as much detail as you have provided here. (Maybe include >Samba version etc.) It's definitely not catching an error and >putting itself into a loop of some kind. >
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
