Subject: Re: [netatalk-admins] afpd grief

From: Tim Bell <[email-masked]>
Date: Fri, 25 Jul 1997 15:00:23 +1000 (EST)

m* wrote:
> 
> my 1.4b2-4 server logs:
> 
> 
> Jul 22 16:28:37 apps afpd[291]: atp_sreq to (5) 32511.164:245
> Jul 22 16:31:19 apps afpd[291]: kill: No such process
> Jul 22 16:31:19 apps afpd[291]: asp_alrm: 6149 timed out
> 
> 
> after which all conections are dropped and a reboot is required
> to restore connectivity.

I am having similar problems; the last three messages I get before
afpd stops working are exactly the same.

> in rtfm and search mode, but pointers would be helpful.

I have no answers, but a very kludgy workaround which I'm using at
the moment -- I restart afpd every morning. Note that a reboot is
not required, nor do you need to stop any other netatalk services.

After the restart, everything is fine, until it breaks again. This
usually happens within the next 24 hours (often 12 hours), so perhaps
I should be restarting every 12 hours.

I am running Debian GNU/Linux 1.3.1 with a 2.0.29 kernel. Netatalk is
from the Debian package version 1.4b2-4. I have a sneaking suspicion
this could be happening only with the Debian netatalk package, in which
case I can take the matter up with the Debian netatalk package person.
If anyone *doesn't* have this problem with the netatalk 1.4b2-4 Debian
package, or *does* have this problem *not* on Debian, please speak up.

In the meantime, I too am in rtfm and search mode.

Tim.
-- 
Tim Bell                                      .--_|\ 
[email-masked]                             /      \
Department of Computer Science               \_.--._/
University of Melbourne, Australia                 v

---

From: K J MacDonald <[email-masked]>
Date: Fri, 25 Jul 1997 11:11:10 +0100 (BST)

Hiya Tim and all,

I've been running the same Debian package (along with the bleeding edge 
Hamm distribution)  here for a couple of months,  without noticing these 
errors.  However, a trawl though my old logs indicates it did indeed 
happen once.

I'm not really using this service at the moment, just using it to test 
some PAM modules I'm writing, and I've recompiled from source against 
libc6.

A brief look at the source indicates that the "atp_sreq to (5) ..." 
messages are coming from libatalk/asp/asp_getsess.c:369.  I don't know 
what this function (asp_attention()) does, but it seems to log this 
message even if the function succeeds (returns 0).

Do you have to reboot the client or the server when this happens?

Best wishes,

Kenny.

|         <[email-masked]> "http://www.glg.ed.ac.uk/~kenny"      |
| Portuguese/English/French Translations/Teaching by Native Portuguese |
|              <[email-masked]> "http://www.nsl.co.uk/tls"              |

---

From: Tim Bell <[email-masked]>
Date: Sat, 26 Jul 1997 09:57:54 +1000 (EST)

> errors.  However, a trawl though my old logs indicates it did indeed 
[snip]
> message even if the function succeeds (returns 0).

Well, further investigation shows that typing your password incorrectly
causes this problem. (I'm not sure if there's any other possible causes,
but I'll stick with this one to start with.) This may account for why
you've only seen it once.

Incidentally, this has been reported as bug #10290 in the Debian bug
tracking system, although not the fact that incorrect passwords are
to blame. (They also have a bug to do with shadow passwords (#9431) --
I'm not sure if they're related, since I do have shadow passwords, but
I'm not seeing the behaviour as described in that bug report.)

> Do you have to reboot the client or the server when this happens?

Just restarting the apfd daemon is enough.

Tim.