I'm wondering if I need to change the order of the processes in the DAEMONS line in rc.conf to prevent a hang on reboot/shutdown if smb shares are mounted. It is almost a 3 minute hang:
Aug 19 16:42:01 providence postfix/qmgr: A178EA64CD: removed Aug 19 16:43:13 providence smbd: [2011/08/19 16:43:13.608240, 0] printing/print_cups.c:110(cups_connect) Aug 19 16:43:13 providence smbd: Unable to connect to CUPS server 192.168.7.15:631 - Connection refused Aug 19 16:43:13 providence smbd: [2011/08/19 16:43:13.623014, 0] printing/print_cups.c:487(cups_async_callback) Aug 19 16:43:13 providence smbd: failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL Aug 19 16:44:49 providence shutdown: shutting down for system reboot Aug 19 16:44:49 providence init: Switching to runlevel: 6
Apparently, the unmount attempt happens immediately after the postfix shutdown and the total time between the time of hang and time of shutdown is 2:48 seconds which seems like forever. (it's probably actually a 2:30 sec. timeout, with 18 secs burned somewhere else)
The DAEMONS line I'm using is:
DAEMONS=(hwclock syslog-ng network hal @netfs @ntpd @sshd @crond !avahi-daemon @mysqld @postfix @cups @samba @apcupsd)
From the error, it looks like smbd attempts to contact cups and gets a connection refused (I have 1 smb printer defined). I don't know whether this is a bug or a problem with the shutdown order. If I manually unmount the smb drives before calling shutdown, then there is no hang. However, I shouldn't need to manually unmount the smb drives as that should be handled automatically.
I can obviously write a simple script that is called on shutdown that does the unmount, but I would rather see if I can identify and fix the issue correctly. Anybody have any thoughts on whether I should move things around in the DAEMONS line? Anybody else seeing this with mounted smb shares? The shares I have are these:
//phoenix/config on /mnt/phx-cfg type cifs (rw) //phoenix/samba on /mnt/phx type cifs (rw) //phoenix/david on /mnt/phx-david type cifs (rw)
Any thoughts? This isn't something that just started today. It has existed for a number of months, but I've just lived with it as this box is rarely rebooted except for kernel updates...