Hi folks,
Both amanda:sendsize and smbclient are OK, it is the interaction that is the
problem.
This started with my question re: read_socket_with_timeout errors
in sendsize.debug. The error is generated from lib/util_sock.c in
samba code. From the logs smbclient is noting a failed open to
amanda:sendsize.
Smbclient takes it own error message as an indicator to
use the next address resolution scheme and continues to attempt to connect.
Sendsize has
noted the socket open failure and declared "session setup failed: code 0";
since the smbclient
process hasn't died yet, sendsize continues to log information from the
smbclient it spawned.
A few things could happen here. Sendsize could kill and respawn an
error-reporting smbclient,
or wait to call the session off until smbclient exits; Smbclient could march
through the host
resolution options before reporting a failed open, thus not confusing
amanda:sendsize.
The reason, probably, that a "wins" first host lookup works for is that the
smbclient file descriptor is not
a socket and a different set of routines are used to perform the open, which
for what
ever reason are more robust or less verbose, thereby not causing sendsize to
make
determination that the session failed. We have a choice of where to make the
fix.
Changing amanda:sendsize to wait for smbclient to exit before declaring a
failed session
would make amanda more robust; changing smbclient to wait until the full
gamut of host resolution
options have been tried before reporting errors would also fix this problem
from an amanda
perspective but may cause other smb-dependent apps to suffer. Having amanda
handle the different
possiblities smbclient presents seems a good way to go..
Does anyone careto look at the code? sendsize.c line 504, maybe...
We have a tentative thesis that the initial problem may be caused by the NIC
being put to sleep
in "powersaving" mode during inactive times (night) which is why we can't
re-produce
the problem during the day. We did uncheck the bit that does this in the 3Com
w2k driver
but didn't reboot the system. We saw no change last night so we'll try
rebooting the
sucker this afternoon.
thanks,
hurf
----------
Todd Pfaff wrote:
> Ok, I think finally understand what Marty is trying to say. Marty, there
> are many people on this list who have been using samba for years and
> understand it very well and how it interacts with amanda, and if we
> couldn't understand the gist of your initial question, don't blame our
> lack of understanding of the english language. :-)
>
> Marty says his samba setup works, but because of the fallback from wins to
> broadcast the lookup takes longer than amanda is willing to wait. Amanda
> times out and as far as amanda is concerned, smbclient failed. I'm not
> even sure what the implications of this are or how to make it work more
> efficiently, I'm just interpreting what he stated.
>
> Marty, is this correct?
>
> Now, this said, I still think the problem is with samba. You should 'fix'
> your samba setup so that it doesn't take so long to do a lookup.
>
> Todd
>
> On Wed, 4 Apr 2001, David Lloyd wrote:
>
> > Marty!
> >
> > I suggest you put your asbestos, flame resistant suit on...
> >
> > > Again: THIS IS NOT AMANDA'S FAULT! IT IS SMBCLIENT'S FAULT!
> >
> > You obviously cannot understand what I am saying, or you have not
> > followed this thread. If you cannot understand English I will have this
> > translated into any other language that I have a character set for:
> >
> > SMBCLIENT CAN CONTACT MY WINDOWS 2000 SERVER. IT DOES NOT FAIL. IT WORKS
> > VIA BROADCAST AND AMANDA FAILS TO SEE THAT IT WORKS.
> >
> > Or to reword this:
> >
> > SAMBA IS ABLE TO CONTACT MY WINDOWS 2000 SERVER; SMBCLIENT CAN CONTACT
> > IT. HOWEVER, IT DOES THIS VIA BROADCAST AND AMANDA FAILS.
> >
> > As far as I'm concerned SMB is working correctly. It is setup to use
> > wins, wins fails and it therefore contacts my Windows 2000 server by
> > broadcast and connects. Perfectly.
> >
> > So how is it smbclient's fault when smbclient works? I can't understand
> > your English...
> >
> > DSL
> >
>
> --
> Todd Pfaff \ Email: [EMAIL PROTECTED]
> Computing and Information Services \ Voice: (905) 525-9140 x22920
> ABB 132 \ FAX: (905) 528-3773
> McMaster University \
> Hamilton, Ontario, Canada L8S 4M1 \
--
Hurf Sheldon
Dir. Research Systems
Program of Computer Graphics
580 Rhodes Hall, Hoy Rd.
Cornell University
Ithaca, N.Y. 14853
voice:607 255 6713 fax:607 255 0806
email: [EMAIL PROTECTED]
http://www.graphics.cornell.edu/~hurf/
