Subject: [netatalk-admins] Afpd dies...

From: Bill Carlson <[email-masked]>
Date: Mon, 29 Nov 1999 12:28:48 -0600 (CST)

Hey all,

I'm trying to update to the latest asun release and running into a
problem.

Solaris 2.6, netatalk 1.42b asun 2.1.3, Mac clients at 8.6.

Startup looks good, afpd starts ok.

Go to the client, Chooser, server is there and looks fine. Username and
password, blam, server disconnected unexpectedly (this takes a minute or
so).

>From syslog:

Nov 24 10:52:07 editorial atalkd[10191]: plumbed /dev/hme0
Nov 24 10:52:07 editorial atalkd[10192]: restart (1.4b2+asun2.1.3)
Nov 24 10:52:07 editorial atalkd[10192]: setsockopt incompatible w/
Solaris STREAMS module.
Nov 24 10:52:09 editorial last message repeated 1 time
Nov 24 10:52:09 editorial atalkd[10192]: zip_getnetinfo for hme0
Nov 24 10:52:10 editorial atalkd[10192]: zip gnireply from 33034.120 (hme0
12)
Nov 24 10:52:10 editorial atalkd[10192]: zip_packet configured hme0 from
33034.120
Nov 24 10:52:19 editorial atalkd[10192]: rtmp_packet gateway 33034.120 up
Nov 24 10:52:37 editorial atalkd[10192]: ready 0/0/0
Nov 24 10:52:55 editorial afpd[10206]: Editorial:AFPServer@Electrical
Differential started on 33034.73:128 (1.4b2
+asun2.1.3)
Nov 24 10:53:21 editorial afpd[10208]: session from 33034.237:248 on
33034.73:129
Nov 24 10:53:21 editorial afpd[10206]: server_child[0] 10208 killed
Nov 24 10:55:41 editorial afpd[10206]: shutting down on signal 15
Nov 24 10:55:41 editorial atalkd[10192]: done

What is the "incompatible w/ Solaris STREAMS module" line about? My
working installation also gives the same error...

The "server_child[0] 10208 killed" is the client logging in, what can I do
to try to figure out why its is dieing? I don't have a core dump or
anything...

Any help appreciated!

Bill Carlson
------------
Systems Programmer    [email-masked]	|  Opinions are mine,
Virtual Hospital      http://www.vh.org/        |  not my employer's.
University of Iowa Hospitals and Clinics	|

---

From: Stephen Welker <[email-masked]>
Date: Tue, 30 Nov 1999 18:10:54 +1100

> Nov 24 10:53:21 editorial afpd[10208]: session from 33034.237:248 on

Bill,

I have had similar problems with afpd when a MacOS 9 client tries to connect
to netatalk on NetBSD server. I had simlar messages in syslog along with the
following message on the console:
    "afpd[...]:dsi_tcp_open: sigaction: Invalid argument"

I tracked the problem down to a possible bug in libatalk/dsi/dsi_tcp.c

If you feel up to modifying source code,

1. edit the file libatalk/dsi/dsi_tcp.c
2. locate the line containing "newact.sa_handler = timeout_handler;"
3. Insert after that line, the following two lines:
    sigemptyset(&newact.sa_mask);
    newact.sa_flags = 0;
4. Go back to the source base directory and recompile. I have found when
making some changes to the source files in libatalk, you have to do a "make
clean" first (it will cause all modules to be recompiled) - it seems that
some make dependancies are not quite working. Then do a "make" followed by
your usual installation procedure.

After I applied the changes above, things seem go along smoothly.

Good luck.

-- 
Stephen Welker

---

From: Stephen Welker <[email-masked]>
Date: Wed, 01 Dec 1999 01:17:13 +1100

> After I applied the changes above, things seem go along smoothly.

Murphy's Law struck within minutes of sending the above message.

Things go smoothly if and only if transfers between the client and server
are small files. If big files are copied, the copy session hangs & times
out, the connection(s) are broken, resulting in the client having to log in
again. Further research has shown the program "QuickBack" was the culprit in
this matter. Why? I do not know. Even so netatalk should not have just given
up so ungracefully.

FWI: QuickBack is a program to mirror a folder to some other disk, folder,
etc.

Finder copies, on the other hand, go without problems - regardless of file
size (tested up 35MB).

The patch I have suggested in my previous email is a best guess as to the
intention of the code written by Adrian Sun - Adrian your help would be
appreciated.

-- 
Stephen