私は約半年前にFreeBSDサーバーにnetatalk3/afpdデーモンをセットアップし、それをMacBookProのネットワーク化されたTimeMachineとして使用しました。ほとんど火をつけて忘れてください。
それから、今月の初めに、バージョン3.1.2,1
から3.1.7,1
にアップグレードしました。
私が再構築できることから、それは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
アップグレードを除いて、サーバー上で何も変更していません。ただそこに座ってそのことをしているだけです。
問題の原因を見つける方法について誰かが私にアドバイスを持っていますか?
暗闇の中での非常にワイルドなショット。 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プロセスがアクティブな場合、アクセスを同期するためにBerkeleyDBロックが使用されます。欠点は、単一のafpdプロセスがクラッシュするとデータベースが破損する可能性があることです。
BerkeleyDB過去に何度も私を噛んだことがあります(他のソフトウェアでは、netatalkを使用していません)ので、問題になる可能性があります。 CDBバックエンドを使用していて、その*.bdb
ディレクトリにBDBファイル(@localstatedir@.../.AppleDB/
など)が存在する場合は、それらのファイルをどこかにバックアップしてから、そこでdb_repair
コマンドを実行してください。コマンド名は、現在のBerkeleyDBバージョンを反映して、db4.9_repair
などになります。