Well, this thread provided me a few interesting hours.
Although I did not share in my previous post, for a long time I had noticed the smb daemon delay only when I booted my entire setup cold. My hardware setup includes the computer, a Linksys WRT54GL 1.1 router, and an ISP sending unit. When I warm-booted only my computer (Ctrl-Alt-Del) I saw no delay with starting the samba service. That observation led me to believe the problem was hardware: on-board NIC, router, or ISP sending unit.
I ran some tests. After several combinations of hard and soft reboots and power-downs of the box, router, and ISP sending unit, I narrowed the cause of my particular delay to the Linksys router, which is running the DD-WRT v23 SP2 firmware. I have been running DD-WRT since spring 2007. As I wrote previously, I don't recall this smb daemon delay always being present. Therefore something else changed since then. (I have the latest DD-WRT firmware but never updated.)
I power down everything at the end of my day. My first boot-up of the day is always cold for all hardware. I have a 15 second delay in my GRUB bootloader menu.lst, which is sufficient time for the router and ISP sending unit to initialize and allow the ntp service on my computer to connect. Apparently with a cold boot this 15 second delay is insufficient for the smb daemon. Therefore the delay seems to be related to the router.
After I narrowed the delay to the router, I next ran several tests without rebooting my computer or the ISP sending unit. I temporarily removed power only to the router, waited a predetermined period, and then restarted the samba service. Repeatedly I witnessed the delay with the smb daemon. I methodically lengthened the waiting period. Eventually I discovered that restarting the samba service three minutes after toggling the power to the router was sufficient to avoid the delay but restarting the service two minutes or less was insufficient and I witnessed the delay. Therefore the router needs somewhere between two and three minutes to do something that seems to cause the delay when starting the samba service.
In my next test I temporarily modified /etc/resolv.conf. My resolv.conf looks like this:
# /etc/resolv.conf
# used to resolve DNS server look-ups
# first query this computer's hosts file
search localhost
# next search this computer for a caching nameserver (e.g., dnsmasq)
nameserver 127.0.0.1
# next query a local network nameserver
nameserver 192.168.1.1
# next query outside DNS servers (e.g., ISP servers)
search blah.blahblahblah.net
That effort unveiled a hefty clue. I stopped the samba service. I unplugged the router. I started the samba service. I witnessed the delay. Then I commented out the option
nameserver 192.168.1.1, which is the IP address of my router. I started the samba service. There was no delay. I restored resolv.conf and I witnessed the delay. I repeated the test several times with the same results. The router was powered off the entire test.
I restored power to the router. I repeated my test with resolv.conf. Same results when I restarted the samba service within three minutes.
Apparently the smb daemon is querying /etc/resolv.conf. Apparently my router is not ready to resolve DNS lookups until somewhere between two and three minutes after booting. What could cause the delay?
I run dnsmasq in the router, which provides DNS lookup caching. I use a hefty secondary hosts file to block advertisement web sites. Refer to the dnsmasq.conf
addn-hosts directive for more information. I temporarily deleted that directive, saved the changes, and rebooted the router. Immediately after the router finished rebooting (not waiting three minutes) I restarted the samba server. I witnessed no delay with the smb daemon.
Next I stopped the samba service. I started the dnsmasq service locally on my box, configured with the same secondary hosts file to block ads. I started the samba service. No delay with the smb daemon.
With this exercise I confirm my remembering no delays at some point in the past. This exercise helped me remember how I previously had configured my system. Sometime this past summer I disabled dnsmasq locally and began running dnsmasq on the router along with the hefty ad blocking file. Disabling the ad blocking at the router but enabling them locally on my computer resulted in the same no delay I recalled from the past.
As one last test I modified my GRUB boot delay time to 20 seconds to allow the local dnsmasq service time to fully load with the hefty ad blocking file and then powered down the entire system. I started everything cold. There was no delay with the smb daemon upon booting. The router was still configured to run dnsmasq but without the hefty ad blocking file.
For me I'll now conclude the delay problem is the hefty dnsmasq secondary hosts file when run on the router.
So what to do about my delay? I suspect the delay is caused by dnsmasq taking its time to respond when the smb daemon queries the resolver, which is dnsmasq at router. Or, the smb daemon waits a few seconds, receives no response from dnsmasq running on the router, which is still loading the ad blocking file, and then the smb daemon queries the ISP DNS servers, which responds immediately. In either case, the smb daemon likely is starting okay, as well as dnsmasq on the router. The few seconds delay I have been witnessing during cold boots is therefore a tolerable annoyance. I also can run dnsmasq locally as well as on the router but use the ad blocking only locally. I prefer to have DNS caching available on the router because I have two test computers I run occasionally. Centralized ad blocking would be nice too but hardly critical for testing boxes. Running dnsmasq in two places duplicates DNS lookup caching, but I probably will never notice any performance difference. I also am aware I should find some motivation to update the router firmware because the associated version of dnsmasq is outdated, not to mention other firmware tweaks.
I did not test previous versions of samba. There are no related error messages in any system or samba logs.
I don't know whether this information helps you, mostlyharmless!
That you can run rc.samba manually after logging in indicates the related samba configuration files probably are okay. Perhaps there is a timing issue similar to mine. For testing, temporarily add a long sleep command in rc.M just prior to executing rc.samba. Say 30 seconds (sleep 30), which is about the time you probably need to login and manually run rc.samba. Or try something extensively long, say sleep 300 (five minutes).
With a stock Slackware installation you also should have at least virtual console 6 available. Try pressing
Alt-F6 or
Ctrl-Alt-F6 while waiting for the sleep period to end. You should be able to login there and then run
ps ax to see which task is the last in the list. That might provide a clue. You also can run
top to see if anything is hanging the system.
If the temporary time delays do not help, then try disabling various services (chmod -x) that are being started in rc.M prior to starting rc.samba.
