hello everyone,
im using slack11 and this afternoon for no apparent reason i started having problems with samba after reboot.

when rc.samba script gets executed during the boot (init level 3), smbd never completes loading ... so it stays there.... stuck and i don't get to the login...


adding debug level 10 to the smbd from within the script i get the following /var/log/samba/log.smbd:

[2009/04/04 04:55:03, 10] param/loadparm.c:set_server_role(4221)
set_server_role: role = ROLE_STANDALONE
[2009/04/04 04:55:03, 5] lib/charcnv.c:charset_name(81)
Substituting charset 'ANSI_X3.4-1968' for LOCALE
.
.(omitting the same msg a few times)
.
[2009/04/04 04:55:03, 5] lib/charcnv.c:charset_name(81)
Substituting charset 'ANSI_X3.4-1968' for LOCALE
[2009/04/04 04:55:03, 7] param/loadparm.c:lp_servicenumber(5112)
lp_servicenumber: couldn't find printers
[2009/04/04 04:55:03, 3] printing/pcap.ccap_cache_reload(117)
reloading printcap cache
[2009/04/04 04:55:03, 5] printing/print_cups.c:cups_cache_reload(71)
reloading cups printcap cache
[2009/04/04 04:55:03, 10] printing/print_cups.c:cups_server(51)
cups server left to default localhost
[2009/04/04 04:55:03, 3] printing/pcap.ccap_cache_reload(223)
reload status: ok
[2009/04/04 04:55:03, 7] param/loadparm.c:lp_servicenumber(5112)
lp_servicenumber: couldn't find printers
[2009/04/04 04:55:03, 7] param/loadparm.c:lp_servicenumber(5112)
lp_servicenumber: couldn't find printers


it can't be that the printers are the problem here because i haven't enabled any print services ...

if i ssh to this machine from another... and i check ps... it will tell me that smbd is running, but nmbd does not... this means the script has never completed executing... additionally trying to access the shares from a winXP pc doesnt work...

(removed the quote due to limitations)


if (from the shh session - its the only login window i can get) i 'kill -9' the running smbd .. (and then i also kill the nmbd that will just start up, as the rc.samba script will get going again and continue loading nmbd -D)... and i re-run as root the whole rc.samba script... the whole script will be run smoothly.... just as it would this morning
and log.smbd will then show


my smb.conf is the following

then there is smb.conf.stargaze and smb.conf.starpool
one set as security use and the other with security share

any ideas why is this happening?

I'm not familiar with that particular script, but I had a similar problem today. My problem was $PATH in a root shell was different than it was from cron. I fixed my problem by changing my script to call programs by full pathnames, /bin/chmod, /usr/bin/rsync, etc.

Alternatively, I could have added a line to the beginning of the script to include /sbin, /usr/sbin, and the like in $PATH.

The fact that your script runs fine interactively but hangs from an automatic call makes me suspect it can't find the binaries it's looking for. Try echoing the path to the log by adding this to /etc/init.d/rc.samba:
Then, next time you ssh in to run the service manually, you can review /var/log/messages to compare the PATH it was using to the one you get from an interactive root shell.

stupid of me i didn't clarify it earlier (then again i was posting at 5am:P)..
the script i am talking about is /etc/rc.d/rc.samba.... that is the standard startup script for samba

and yes the smbd and nmbd commands run from within, contain the full paths

nass

Maybe try ssh from another machine and set the /etc/rc.d/rc.samba script to non-excutable eg. chmod -x /etc/rc.d/rc.samba. Then restart your server and then see if you can login to the machine.

The smb.conf file might be corrupt, there maybe some text garbage in the file that was left by the text editor you used, this has happened to me when using windoze based text editors in the past, occasional some linux editors can do the same thing, create a new smb.conf and see if the same thing happens.

To make things cleaner, you should add the following to the [global] section of smb.conf :
At the very least it will get rid of the warnings/errors about finding/loading printers, and may speed up smb start as well.
You may also want to run testparm to check/confirm your smb.conf.

Now then: this is always the case: both during boot and during cron jobs there's no "default" $PATH set. If not set in the script (or in a "global" script that gets called by all your cron / boot scripts there is no $PATH.

That said, I doubt anything at all would happen if smbd was not found. Most likely cause is indeed invalid characters (like windows newlines) or some other strange option. Another thing that occurs to me is that this may be caused by the run order of the scripts. If you try to locate where /etc/rc.d/rc.smbd is run and try to move it to the end of the invocations. My estimate is that this gets called in /etc/rc.d/rc.M; you could comment it out there and place those lines in /etc/rc.d/rc.local (which is your custom script which gets run last iirc) This would rule out that some other "thing" has not started yet or is starting and causing a deadlock. (one thing could be that your network card is still initializing from DHCP... or another such thing...)

Of course there's a "default" path for cron jobs and at boot time. It's just much shorter than the interactive path, having not sourced /etc/profile and similar. That can bite when you have, for example, multiple versions of programs installed for testing, and forget to include a fully-qualified path in a couple of places.

Now that's unlikely in the system rc.samba script, so something must have changed. If it's stock Slack, use slackpkg to remove and reinstall the package. (Or use removepkg if Slack11 doesn't have slackpkg, I can't remember). Remember to save your smb.conf, and see if it will run with the stock config file.

Edit: Of course, try the less intrusive methods above before moving on to package management. That's just one more option if smaller changes don't pan out.

in the end, Ramurd was right

i bind samba to some vpn interfaces too...
and in rc.M i was initializing the tun interfaces AFTER the samba deamons..

i switched the init order and voila
everything back to normal!

thank you all for your help!
nass

glad to hear it's all sorted out

Glad that you fixed the problem, things can be a bit vague sometimes :-)

as for:
"officially" the PATH variable is empty by default for both bootup scripts and cron. It is configurable, but there's a reason that all startup scripts use the full path to programs. The reason being that PATH is not initialized yet. You can try it with a cron job that simply echoes $PATH (or a boot script for that matter, you can see what's in the variable then)