On May 21, 2010, at 11:24 AM, Les Mikesell <lesmikesell at gmail.com> wrote: > On 5/21/2010 9:44 AM, Whit Blauvelt wrote: >> On Fri, May 21, 2010 at 10:04:36AM -0400, Ross Walker wrote: >> >>> By any chance did someone add smbd to xinetd? >>> >>> If so then xinetd has the port open and the smbd process will not >>> bind. >> >> Nope. Not sure that would explain why a slight difference in how it's >> invoked, through the same init.d script, makes the difference in >> whether it >> runs. That is: >> >> sh /etc/init.d/smb start (and "/usr/sbin/smbd -D") >> >> which always works from console, differs from >> >> /etc/init.d/smb start (and "service smb start" too) >> >> which doesn't ever work on this box, how? This is when smb starts >> with >> "#!/bin/sh" anyway. Only thing I can figure is that there may be a >> subtle >> difference in timing, a slowing down just enough to make the startup >> tolerant of hardware that's right on the margin. There's no >> significant >> difference (if any) in envars. > > The only difference here 'should' be that explicitly running 'sh' will > invoke your own shell aliases and search PATH to execute sh, where if > you omit it you'll get the #!/bin/sh interpreter specified in the > script > itself. Is there anything in your aliases or anything before /bin in > PATH where the working shell might be found? > > Or, perhaps this difference is coincidental and something is randomly > killing smbd. You might be able to see something if you comment out > the > nmbd startup in the script and > strace -f /etc/init.d/smb start > but it will only be useful if smbd dies and you can see a failing > system > call causing it. Or maybe a corrupt env file in /etc/profile.d? -Ross