我在大约半年前在我的FreeBSD服务器上build立了一个netatalk3 / afpd守护进程，并将它用作我的MacBook Pro的联网TimeMachine。 非常火，忘了。
然后，本月初，我从版本3.1.2,1升级到3.1.7,1 。
从我可以重build的事情来看，这是FreeBSD 10.0 – > 10.1升级的一部分。
我花了一段时间才注意到守护进程已经不在运行了， 实际上，一段时间后，MacBook开始抱怨错过了备份。
看着这个问题，似乎netatalk3守护进程不断重启，但即使我增加了日志级别在/usr/local/etc/afp.conf使用log level = default:debug ，似乎没有任何提示在什么原因重新启动是：
Jan 24 19:06:24.841243 netatalk[8651] {netatalk.c:386} (note:Default): Netatalk AFP server starting Jan 24 19:06:24.843728 cnid_metad[8653] {cnid_metad.c:510} (note:AFPDaemon): CNID Server listening on localhost:4700 Jan 24 19:06:24.844380 netatalk[8651] {afp_avahi.c:80} (info:AFPDaemon): Registering volume 'TimeMachine' with UUID: '<some UUID>' for TimeMachine Jan 24 19:06:24.844434 netatalk[8651] {afp_avahi.c:94} (info:AFPDaemon): hostname: <hostname> Jan 24 19:06:24.844451 netatalk[8651] {afp_avahi.c:106} (info:AFPDaemon): Registering server '<hostname>' with Bonjour Jan 24 19:06:24.845279 netatalk[8651] {afp_avahi.c:302} (info:AFPDaemon): Successfully started avahi loop. Jan 24 19:06:24.845319 netatalk[8651] {netatalk.c:456} (note:Default): Registered with Zeroconf Jan 24 19:06:24.845356 netatalk[8651] {netatalk.c:218} (info:Default): child[8652]: exited 1 Jan 24 19:06:25.843370 netatalk[8651] {netatalk.c:254} (note:AFPDaemon): Restarting 'afpd' (restarts: 1) Jan 24 19:06:25.845151 netatalk[8651] {netatalk.c:218} (info:Default): child[8654]: exited 1 Jan 24 19:06:26.842367 netatalk[8651] {netatalk.c:254} (note:AFPDaemon): Restarting 'afpd' (restarts: 2) Jan 24 19:06:26.844195 netatalk[8651] {netatalk.c:218} (info:Default): child[8655]: exited 1 Jan 24 19:06:27.846723 netatalk[8651] {netatalk.c:254} (note:AFPDaemon): Restarting 'afpd' (restarts: 3) ...
/var/log/messages也没有。 除了10.1升级，我还没有改变服务器上的任何东西; 它只是坐在那里做它的事情。
有没有人有一些build议，我怎么去寻找问题的原因？
在黑暗中只是一个非常狂野的镜头; netatalk文档告诉这个：
AFP协议主要是通过ID而不是通过名称来引用文件和目录。 Netatalk需要一种以持久的方式存储这些ID的方法，以实现这个几个不同的CNID后端可用。 CNID数据库默认位于@ localstatedir @ / netatalk / CNID /（volumename）/。AppleDB /目录中。
CDB
"Concurrent database", backend is based on Oracle Berkley DB. With this backend several afpd daemons access the CNID database directly.如果一个卷有多个afpd进程处于活动状态，则使用Berkeley DBlocking来同步访问。 缺点是，单个afpd进程的崩溃可能会破坏数据库。
BerkeleyDB在过去曾多次咬伤我（其他软件，我没有使用netatalk），我认为这可能是问题。 如果您正在使用CDB后端，并且在@localstatedir@.../.AppleDB/目录中存在BDB文件（ *.bdb左右），则可以尝试在某处备份这些文件，然后在那里运行db_repair命令。 命令名称可能是db4.9_repair或类似的，反映了当前的BerkeleyDB版本。