1

I set up a netatalk3 / afpd daemon on my FreeBSD server about half a year ago and used it as networked TimeMachine for my MacBook Pro. Pretty much fire and forget.

Then, beginning of this month, I upgraded from version 3.1.2,1 to 3.1.7,1.
From what I can reconstruct, that happened as part of the FreeBSD 10.0 --> 10.1 upgrade.

It took me a while to notice that the daemon is not running anymore; actually, the MacBook began to complain about missed backups after a while.

Looking into the issue, it seems the netatalk3 daemon keeps restarting, but even though I've increased the log level in /usr/local/etc/afp.conf using log level = default:debug, there does not seem to be any hint at what the reason for the restarting is:

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)
  ...

Nothing in /var/log/messages either. Apart from the 10.1 upgrade, I haven't changed anything on the server; it's just been sitting there doing its thing.

Does anyone have some advice for me how to go about finding the cause of the problem ?

6
  • Isn't this a thing for a freeBSD mailing list/forum? I'd try there :-) Looks like a pkg maintainer has some work to do :-)
    – DutchUncle
    Jan 28, 2015 at 21:34
  • or go straight here: bugs.freebsd.org/bugzilla
    – DutchUncle
    Jan 28, 2015 at 21:37
  • I was afraid someone was going to say that, but you're right of course. I was just hoping someone has an idea why a server on FreeBSD in general would keep restarting like that - no error message, no hint in any logs ?!?
    – ssc
    Jan 28, 2015 at 21:51
  • Yep, indeed, you've got a case of buggy port/pkg, and lack of beta/production testers :-/
    – DutchUncle
    Jan 28, 2015 at 22:08
  • 1
    I couldn't get myself to signing up to yet another mailing list or forum just for a single question, but I got a pointer in IRC #freebsd, updating post...
    – ssc
    Jan 28, 2015 at 22:19

1 Answer 1

1

Just a very wild shot in the dark; netatalk documentation tells this:

The AFP protocol mostly refers to files and directories by ID and not by name. Netatalk needs a way to store these ID's in a persistent way, to achieve this several different CNID backends are available. The CNID Databases are by default located in the @localstatedir@/netatalk/CNID/(volumename)/.AppleDB/ directory.

cdb

"Concurrent database", backend is based on Oracle Berkley DB. With this backend several afpd daemons access the CNID database directly.

Berkeley DB locking is used to synchronize access, if more than one afpd process is active for a volume. The drawback is, that the crash of a single afpd process might corrupt the database.

BerkeleyDB has bitten me so many times in the past (with the other software, I have not used netatalk) that I think it might the problem, yet again. If you are using CDB backend and there are BDB files (*.bdb or so) present in that @localstatedir@.../.AppleDB/ directory, you might try to backup those files somewhere and then run db_repair command there. The command name might be db4.9_repair or similar, reflecting the current BerkeleyDB version.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .