Subject: [netatalk-admins] Oy! Is this what you guys have been talking all about?
From: PayPC System Mail Subscriber (spammail@quanta.paypc.com)
Date: Sun Nov 29 1998 - 22:05:40 EST
The following is what I got by dragging a Metrowerks directory (80MB of
stuff, including the IDE 2.0, plugins, MSL, and the includes & libs) from a
local hard drive TO a netatalk volume:
Nov 29 21:27:47 quanta afpd[22871]: session from 41201.173:250 on
65280.180:129
Nov 29 21:27:47 quanta afpd[22871]: randnum/rand2num login: nfsadmin
Nov 29 21:27:47 quanta afpd[22871]: login nfsadmin (uid 1011, gid 102)
Nov 29 21:38:28 quanta afpd[128]: asp_alrm: 22871 timed out
Nov 29 21:38:48 quanta afpd[22871]: 576.34KB read, 44337.20KB written
Nov 29 21:38:48 quanta afpd[128]: server_child[0] 22871 done
Quickie background: Intel Linux 2.0.33+ (security patches and MM fixes,
mostly), netatalk preasun 2.1.0a was running at the time. The area being
written to was owned exclusively by the account used to login. OS 8.5, ASIP
3.8.1, yadayada, PowerMac 8500/120, normal 10BT.
As you can see, it got about 1/2 way thru the copy. At a *ROUGH* guess,
about 1.5-2 minutes. The server "abruptly terminated service", killing the
copy, and upon clicking STOP, the client machine with it. OW.
So. Is this the offending "crasher" I've been hearing about? Also, judging
by the log entry, this implies a tickle wasn't received or responded to. But
I'm 99.9% sure the xfer was proceeding fine. Is the need for "tickling"
obviated by the reception of data from the host? (If not in "theory", then
in practice? I suppose I *could* install ASIP Server 6.x and ethernet sniff
the wire and see how it deals with this... but it seems like the alarm has
genuinely gone off, SIGTERMing the client's afpd. This 1-2 minutes of time
into the copy is also suspicious, since I know many ASIP timeouts default to
this region... For what it's worth, I posit the possibilities as follows:
1) the asp tickle (server->client) isn't sent properly during heavy i/os by
netatalk
2) the asp tickle isn't received by the ASIP 3.8.1 client properly (or
acknowledge timely enough).
3) the tickle isn't necessary during "demonstrated" i/o within the past
tickle interval, because asip 3.8.x clients may not be able to respond to it
properly during such times.
I'm sure I've DRAMATICALLY oversimplified many aspects of this complicated
problem... however, in sniffing through the asp code, the only way that log
entry fires is if a tickle's not responded to.
=Rob=
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:47 EST