[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk
Subject:    [Netatalk-admins] FreeBSD 8.2RC3 "Hangs"
From:       Mailing Lists <lists.accumulator () gmail ! com>
Date:       2011-02-09 5:48:39
Message-ID: AANLkTinWTQdhj+rtzBh7sav4Ts6AGKnsSKAq7RnChNBV () mail ! gmail ! com
[Download RAW message or body]

I've installed the netatalk-2.1.5 port on FreeBSD 8.2RC3 and am
experiencing some interesting issues.  It seems as though, after a
night of transferring around 600GB of data, that the system started
having some issues with processes hanging:

username    2542  0.0  0.4 33640  6948  ??  D     2:53PM  26:20.14
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        2545  0.0  0.9 22676 14076  ??  D     2:53PM   0:49.56
/usr/local/sbin/cnid_dbd /mnt/data/master-backup/.AppleDB 7 5 default
log_note
username    2612  0.0  0.9 40392 13376  ??  D     3:24PM   1:40.31
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        2775  0.0  0.2 31592  3736  ??  D     4:53PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        2848  0.0  0.2 31592  3716  ??  D     5:24PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        2963  0.0  0.2 31592  3716  ??  D     6:24PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3071  0.0  0.2 31592  3716  ??  D     7:24PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3180  0.0  0.2 31592  3716  ??  D     8:24PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3288  0.0  0.2 31592  3716  ??  D     9:24PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3379  0.0  0.2 31592  3716  ??  D    10:12PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3380  0.0  0.2 31592  3716  ??  D    10:14PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3408  0.0  0.2 31592  3716  ??  D    10:24PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3516  0.0  0.2 31592  3716  ??  D    11:24PM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3627  0.0  0.2 31592  3716  ??  D    12:24AM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3739  0.0  0.2 31592  3716  ??  D     1:24AM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3819  0.0  0.2 31592  3716  ??  D     2:00AM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20
root        3822  0.0  0.2 31592  3716  ??  D     2:01AM   0:00.01
/usr/local/sbin/afpd -n hostname -s /usr/local/etc/AppleVolumes.system
-f /usr/local/etc/AppleVolumes.default -g nobody -c 20

This is running atop a ZFS pool on a system with 1.5GB of RAM.  The
kernel settings have been tweaked so as to help ZFS to run without
dying due to running out of kernel memory space and such, however
after this long run I found the afore-noted processes unkillable. I've
tried to kill them in a number of ways, all without success. They
don't appear to be zombie processes nor do they seem to have lost
their parents I don't believe.

The strange thing is that the connection dropped off and I'm not
seeing  a real indication of an error as to why and then further I'm
seeing that when I attempt to reconnect, even after running
`/usr/local/etc/rc.d/netatalk restart` or stop/start that A) it takes
a very long time for Mac OS X to even throw up the authentication
dialog and then after seeming to go away, it never mounts the
volume...

Any thoughts on this issue?  There definitely seems to be something awry here.

Just a few other notes, I've been seeing this in the logs quite a bit:
Feb  3 20:09:29 hostname afpd: pam_sm_close_session(): no utmp record for afpd

Also have seen this (which must stem from the port compilation or
needing to turn up the verbosity of the cnid daemon):
Feb  8 14:53:48 nasi cnid_dbd[2545]: Set syslog logging to level: LOG_NOTE

I also had issues with some hangs on the server apparently due to zfs
issues and after a hard restart I needed to delete the .AppleDB folder
to allow it to work without the CNID daemon going nuts and never
allowing a read-write mount of the volume/share, however that seems
fine now after just simply deleting the database folder after a hard
reboot (hope that's safe, but it seems to work fine).

Would appreciate any help!!!


-George

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Netatalk-admins mailing list
Netatalk-admins@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-admins
[prev in list] [next in list] [prev in thread] [next in thread]