samba - May 2000 - smbmount problems when mounted share goes offline.

(using samba-2.0.7 on Debian Linux 2.2.15)

Hi,

  I'm wondering how do I get around the problem when you smbmount a share on
a win32 machine and that machine reboots, the mount becomes a blackhole. If
you attempt an 'ls', 'df' or anything that would access that
mount point the
program then goes into a state of void and cannot be killed, leaving the
proc open until reboot (another way?) and the mount "busy".

  Any suggestions on how to unmount the share and remount it (remount
readonly?)? I'm not much into testing this since it requires me to use a
production server. Also, I've since made the kernel smbfs a module. Will
that help? Just rmmod it if it blackholes?

Thanks.

-reid

On Thu, 1 Jun 2000, Reid Sutherland wrote:
>   I'm wondering how do I get around the problem when you smbmount a
share on
> a win32 machine and that machine reboots, the mount becomes a blackhole. If
> you attempt an 'ls', 'df' or anything that would access
that mount point the
> program then goes into a state of void and cannot be killed, leaving the
> proc open until reboot (another way?) and the mount "busy".
You are not the first to mention problems with mounts becoming unuseable.

If you get processes that cannot be killed (even with 'kill -KILL') it
is
most likely a kernel problem. You can find out where it is waiting by
doing 'ps -l n <pid>', this will output a number for WCHAN that
you can
look up in your System.map.

# ps -l n 17308
  F S   UID   PID  PPID  C PRI  NI ADDR    SZ  WCHAN TTY        TIME CMD
040 S     0 17308     1  0  60   0    -   676 1113f6 ?          0:00 /sbin/mount

My System.map contains:
...
c01113e4 T sys_pause
c0111400 T pci_alloc_consistent
...

1113f6 means that it is waiting somewhere in sys_pause (which makes sense
if you look at the smbmount source, not sure why the c0 isn't being output
too).

'ps -l <pid>' will do the lookup for you, but the numbers could be
used to
find out exactly where it is blocking. ps -l needs to be able to find the
right System.map, 'man ps' for more on that.

>   Any suggestions on how to unmount the share and remount it (remount
'kill -KILL <pid>', 'umount /mntpoint', 'mount -t
smbfs ... /mntpoint'
works for me when I kill a server.

I can easily reproduce the "it stops working" part of your problem
(see
other mail with patch), but I can't make a process hang.

/Urban

Hello

There have been a few reports on mounted shares that stop working, some of
these mention that the server was rebooted. There are probably other
reasons for some of the problems, but here is a patch for one smbmount
problem. But first a desciption of the problem it tries to fix.

samba-2.0.7 on both ends. client is 2.4.0-test1-ac2 + patch to make smbfs
behave like in 2.2.16-pre (shouldn't matter at all)

client				server (b, exports the share la)
------				------
				# /usr/local/samba/bin/smbd
# mount -t smbfs //b/la /ha
# ls -al /ha
total 1
...
# ps -e | grep smb
16135 ?        00:00:00 mount.smbfs
				# killall smbd
				  (pretend the server died)
# ls -al /ha
   (after a longish delay)
ls: /ha: Input/output error
# ps -e | grep smb
#

Nothing! smbmount is gone, starting the smbd on the server will not
help since smbfs needs the now dead smbmount to reconnect it.

# umount /ha

Recompile, after applying the patch below, install and repeat the above
steps ... here is the important difference:
				# killall smbd
# ls -al /ha
   (after a longish delay)
ls: /ha: Input/output error
# ps -e | grep smb
17308 ?        00:00:00 mount.smbfs

It's still around! Starting the smbd again could make the connection work
again ... and it does.

				# /usr/local/samba/bin/smbd
# ls -al /ha
total 1
...

It also works if I bring the server box down and then up (the delay before
claiming an error on ls becomes longer). I have not tested this vs a
rebooting windows box, but it should be the same.

/Urban


--- samba-2.0.7-orig/source/client/smbmount.c	Wed Apr 26 01:06:42 2000
+++ samba-2.0.7/source/client/smbmount.c	Wed May 31 18:32:40 2000
@@ -342,13 +342,17 @@
 		}
 #endif
 
-		/* Wait for a signal from smbfs ... */
-		CatchSignal(SIGUSR1, &usr1_handler);
-		pause();
+		/* Wait for a signal from smbfs ... but don't continue
+                   until we actually get a new connection. */
+		c = NULL;
+		while (!c) {
+		    CatchSignal(SIGUSR1, &usr1_handler);
+		    pause();
 #ifdef SMBFS_DEBUG
-		DEBUG(2,("mount.smbfs: got signal, getting new socket\n"));
+		    DEBUG(2,("mount.smbfs: got signal, getting new socket\n"));
 #endif
-		c = do_connection(service);
+		    c = do_connection(service);
+		}
 	}
 
 	smb_umount(mount_point);

>Date:   Wed, 31 May 2000 11:02:58 -0400
>From:   "Reid Sutherland" <reid@isys.ca>
>To:     <samba@samba.org>
>Subject: smbmount problems when mounted share goes offline.
>Message-ID: <000901bfcb11$4ee0c860$d250dfd8@isys.ca>
>MIME-Version: 1.0
>Content-Type: text/plain;
>charset="iso-8859-1"
>ontent-Transfer-Encoding: 7bit
>
>using samba-2.0.7 on Debian Linux 2.2.15)
>
>Hi,
>
>  I'm wondering how do I get around the problem when you smbmount a
share
on
>a win32 machine and that machine reboots, the mount becomes a blackhole. If
>you attempt an 'ls', 'df' or anything that would access that
mount point
the
>program then goes into a state of void and cannot be killed, leaving the
>proc open until reboot (another way?) and the mount "busy".
>
>  Any suggestions on how to unmount the share and remount it (remount
>readonly?)? I'm not much into testing this since it requires me to use a
>production server. Also, I've since made the kernel smbfs a module. Will
>that help? Just rmmod it if it blackholes?
>
>Thanks.
>
>-reid
This is similar to my previous complaint of the NT servers 'timing out'
my
smbmount connections and smbmount not auto-reconnecting.

My solution to this problem was to create a script which monitorings the
smbmount'd partitions using df.  If I get an error (I/O or Broken Pipe are
what I've seen) the script will unmount the drive and do a mount -a to
remount it.

Originally I would run this check script once every thirty minutes and I
would get notifications that it was having to remount the drives throughout
the day and night.  I then changed it to check every five minutes to see if
I could get a better idea when it's happening, but the result is a
'heartbeat' to the NT server every five minutes as I do a df on the
drive.
Since I switched to 5 minute checks I hardly ever see the mount point down
and have to remount.

Now I realize this isn't exactly what your describing, but the other
advantage to this script is that if for some reason the NT server(s) get
rebooted or otherwise drop their shares my script will automatically remount
the drives for me.

I've attached the perl script and a sample data file.

Note: The script assumes that you have setup the mounts in your /etc/fstab
file so that mount -a would remount them for you.

Let me know if you have any questions.

BTW I think I spoke with you via phone a few months back on a hacker
problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_nt_mounts.dat
Type: application/octet-stream
Size: 26 bytes
Desc: not available
Url :
http://lists.samba.org/archive/samba/attachments/20000531/a7a908c7/check_nt_mounts.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_nt_mounts.pl
Type: application/octet-stream
Size: 1250 bytes
Desc: not available
Url :
http://lists.samba.org/archive/samba/attachments/20000531/a7a908c7/check_nt_mounts-0001.obj